www.mikrocontroller.net

Forum: FPGA, VHDL & Co. (asynchronen) Reset vermeiden. oder nicht?


Autor: Konstantin L. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein erstklassiges Forum. Ich habe nun eine ganze Weile die fpga/vhdl 
Beisträge durchgearbeitet.
Dennoch, oder vielleicht deshalb, bin ich etwas durcheinander. Ich habe 
wohl weniger verstanden als ich zwischendurch dachte und weil in einigen 
Threads durchkam, zu was man wohl nach einer einsemestrigen Vorlesung in 
der Lage sein sollte, versuche ich nun Lücken aufzufüllen. Ich bin mir 
sehr wohl bewusst, daß die Lernfähigkeit meines Hirns nicht mit jemand 
im studentischen Alter mithalten kann, aber was muss das muss...

Frage bezieht sich auf den Reset.
Ich habe für mich aus den Beiträgen gezogen, das ein Reset nicht gemacht 
werden soll. Ein asynchroner auf gar keinen Fall. Die Begründung so wie 
ich es verstanden habe ist, daß man nicht 100% sicher sein kann, daß 
alle FF bei jeder Pulsform das Signal mitbekommen und dann teilweise 
zurückgesetzt sind, teilweise nicht. Ein emv spike auf dieser Leitung 
wäre z.B. ein solcher Auslöser.

Nun liest man aber in fast allen Büchern (und nicht nur exotischen 
sondern auch den empfohlenen Lehrbüchern) Beschreibungen mit asynchronem 
Reset. Schreiben die ohne nachdenken voneinander ab, denn wenn das 
Problem so gravierend ist, würde ja gefährliche Praxis vermittelt.

Zur allgemeinen reset frage noch einige konkrete. Reset würde von den 
Tools intern über ein reset Netz verteilt. ist das richtig? Wenn das so 
ist sollte doch das Problem, daß die FF reset zeitlich extrem versetzt 
bekommen entschärft sein? Und einen noch so kurzen Puls bekommen doch 
trotzdem alle angeschlossenen FF irgendwann mit. Wenn nach einem reset 
eine gewisse Zeit kein clk anliegt, gibt es dann Probleme mit nicht 
zurückgesetzten FF? Als gefährlich war ja auch das Szenario beschrieben 
wenn reset eben unmittelbar vor clk eintritt. Stoppt der reset Knopf den 
Takt - keine Probleme?

Sollte man dann ein reset Signal eintakten und im ganzen Design 
taktsynchron verwenden? Bei Herrn Miller ist ja eine Schaltung 
vorgestellt, die einen (nahezu) beliebig kurzen Puls auf Taktlänge 
bringt. Dann wäre nach einem Reset alles im fpga wenigstens auf default 
Werten was für mein Gefühl irgendwie wünschenswert ist. Ich denke an 
Automaten, default Registerwerte usw. die doch zum Rest des 
zurückgesetzten Systems passen müssen.

Wie gesagt, ich habe riesige Verständnislücken das ist mir bewusst. Die 
sollen wenn möglich gefüllt werden, das kann auch länger als die Zeit 
einer Vorlesung dauern.

viele Grüße

Autor: Sym (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Sache mit dem Reset ist mehr oder minder eine Geschmackssache, ob 
synchron oder asynchron. Problematisch ist der asynchrone Reset deshalb, 
weil er metastabil sein kann und die Removal Time verletzt sein kann. In 
der Praxis heißt das, dass bei unsauberem Design Probleme entstehen: 
Manche Register werden resettet, manche gar nicht und manche einen 
Taktzyklus früher oder später.

Reset wird bei den FPGAs über ein Taktnetz verteilt. Das heißt aber noch 
lange nicht, dass der Reset alle Register zeitgleich erreicht. Oft wird 
daher beim asynchronen Reset folgendes empfohlen: Asynchron anlegen und 
synchron zurücksetzen. Dadurch wird der Reset eingetakt und Probleme mit 
der Metastabilität umgangen. Wobei für synchrone Rücksetzen die Removal 
Time beachtet werden muss d.h. in diesem Ausnahmefall macht es 
möglicherweise Sinn auf der fallende Flanke (statt der steigenden) das 
Resetsignal zurückzusetzen.

Autor: Konstantin L. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Oft wird
daher beim asynchronen Reset folgendes empfohlen: Asynchron anlegen und
synchron zurücksetzen."

Könntest du das mit einem pseudo Code Schnipsel konkretisieren? ich bin 
mir nicht ganz sicher, daß ich dir vollständig richtig folge.
Danke

Autor: Blubbi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke er meint das man den Reset einfach mit 1-2 FF's 
Einsynchronisieren sollte.

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

Bewertung
0 lesenswert
nicht lesenswert
Sym schrieb:
> Reset wird bei den FPGAs über ein Taktnetz verteilt.
Aber garantiert nicht bei allen!

> Reset wird bei den FPGAs über ein Taktnetz verteilt. Das heißt aber
> noch lange nicht, dass der Reset alle Register zeitgleich erreicht.
Genau das muss ein Taktnetz aber garantieren.

> Dadurch wird der Reset eingetakt und Probleme mit
> der Metastabilität umgangen.
Bleib mit der Metastabilität aus diesem Thema raus. Es ist zum 
überwiegendsten Teil ein Problem von simplen Laufzeiten.
http://www.lothar-miller.de/s9y/categories/35-Eins...
Ich würde wetten, du hast bei Taktfrequenzen kleiner 200MHz bei 
aktuellen FPGAs noch nie ein Problem mit einem metastabilen FF gehabt. 
Sehr wohl aber mit unterschiedlichen Laufzeiten wegen eines nicht 
artgerecht einsynchronisierten Eingangs.
Und ich hätte sehr gute Chancen auf einen Gewinn...  ;-)

Kurz: ob ein asynchroner Reset beschrieben werden darf oder sogar 
sollte, hängt von der Zielarchitektur ab.
Siehe auch den Beitrag "Xilinx und die Resets"

Konstantin L. schrieb:
> Reset würde von den Tools intern über ein reset Netz verteilt.
Es gibt ein globales Resetnetzwerk, an das alle FFs angeschlossen 
sind. Aber weil in deinem Design garantiert (!) nicht für alle Elemente 
ein Reset beschreiben ist, kann dieses Netz nicht verwendet werden.
Fazit: Der Reset wird händisch gereoutet...
Nicht mehr...

> Und einen noch so kurzen Puls bekommen doch
> trotzdem alle angeschlossenen FF irgendwann mit.
Nein.
Das gibt dann auch lustige Fehler, wenn dir das halbe Design 
zurückgesetzt wird. Und jedesmal eine andere Hälfte...  :-o

> Bei Herrn Miller ist ja eine Schaltung vorgestellt,
> die einen (nahezu) beliebig kurzen Puls auf Taktlänge bringt.
Das schnelle Reagieren macht für einen Reset keinen Sinn.
Ich gehe (wenn ich mal unbedingt muß) eher den anderen Weg: das externe 
Resetsignal muß mindestens 100 Taktzyklen stabil anliegen, sonst wars 
evtl. nur ein EMV-Spike...

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Frage ist doch eigentlich, wofür der Reset gut sein soll. Und genau 
daraus ergeben sich dann die Dos bzw. Donts.

FPGA oder ASIC?

Muss der Chip wirklich im Betrieb von aussen zurückgesetzt werden 
können?

Und wenn ja, wirklich alles oder nur ein paar Statemachines/Register?

Geht es um sinnvolle Startupwerte nach dem Laden des FPGAs?

Geht es nur um einen vernünftigen Start der Simulation, damit man nicht 
die U->X-Rotpest auslöst?

Von daher sind IMO Generalisierungen ala "async Reset ist des Teufels" 
oder "Ohne Resetpin ist die Spec unvollständig" wenig hilfreich.

Autor: Sym (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
>> Reset wird bei den FPGAs über ein Taktnetz verteilt. Das heißt aber
>> noch lange nicht, dass der Reset alle Register zeitgleich erreicht.
> Genau das muss ein Taktnetz aber garantieren.

Das Taktnetz erlaubt es ein Signal verzögerungsärmer zu verteilen. 
Verletzungen der Removal time kann es aber nicht verhindern. Bei einer 
Removal Time Violation des Resets startet ein Register früher als ein 
anderes.

> Ich würde wetten, du hast bei Taktfrequenzen kleiner 200MHz bei
> aktuellen FPGAs noch nie ein Problem mit einem metastabilen FF gehabt.
> Sehr wohl aber mit unterschiedlichen Laufzeiten wegen eines nicht
> artgerecht einsynchronisierten Eingangs.
> Und ich hätte sehr gute Chancen auf einen Gewinn...  ;-)

Wenn du 2x einsynchronisieren als ordnungsgemäß betrachtet, dann hast du 
verloren. Manchmal bringt tatsächlich eine 1-2 weitere Stufen die 
erhoffte Stabilität.

>> Und einen noch so kurzen Puls bekommen doch
>> trotzdem alle angeschlossenen FF irgendwann mit.
> Nein.
> Das gibt dann auch lustige Fehler, wenn dir das halbe Design
> zurückgesetzt wird. Und jedesmal eine andere Hälfte...  :-o
Richtig. Ein Puls muss nicht vom allen FFs gesehen werden.

>> Bei Herrn Miller ist ja eine Schaltung vorgestellt,
>> die einen (nahezu) beliebig kurzen Puls auf Taktlänge bringt.
> Das schnelle Reagieren macht für einen Reset keinen Sinn.
> Ich gehe (wenn ich mal unbedingt muß) eher den anderen Weg: das externe
> Resetsignal muß mindestens 100 Taktzyklen stabil anliegen, sonst wars
> evtl. nur ein EMV-Spike...
Zeit hat man. Den asynchronen Reset sollte man in die gewünschte 
Taktdomain reintakten. Allerdings darf man das Resetsignal nicht knapp 
nach der Taktflanke der FFs zurücksetzen, weil man sonst die Removal 
Time verletzt. Ein möglicher Weg ist es daher, das Reset auf die andere 
Flanke zurückzusetzen. (d.h. FFs auf rising edge, reset wird bei falling 
edge deaktiviert).

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

Bewertung
0 lesenswert
nicht lesenswert
Sym schrieb:
> Allerdings darf man das Resetsignal nicht knapp nach der Taktflanke der
> FFs zurücksetzen, weil man sonst die Removal Time verletzt.
Die Haltezeit von FFs in aktuellen FPGAs ist 0ns. Es gibt nur noch eine 
Setup-Zeit zu beachten.

> Ein möglicher Weg ist es daher, das Reset auf die andere Flanke
> zurückzusetzen. (d.h. FFs auf rising edge, reset wird bei falling
> edge deaktiviert).
Damit verdoppelst du virtuell die Taktfrequenz. Denn im ersten 
Taktzyklus nach dem Reset steht nur die Hälfte der Zeit bereit, damit 
für die FFs bei der nächsten Flanke die Setup-Zeit eingehalten wird...

Sym schrieb:
> Wenn du 2x einsynchronisieren als ordnungsgemäß betrachtet, dann hast du
> verloren. Manchmal bringt tatsächlich eine 1-2 weitere Stufen die
> erhoffte Stabilität.
Dann hast du ein anderes Problem. Bei Taktfrequenzen kleiner 200MHz ist 
Metastabilität auf jeden Fall kein Thema. Siehe dazu den 
Beitrag "Detailbetrachtungen zur Metastabilität"

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
> Die Haltezeit von FFs in aktuellen FPGAs ist 0ns. Es gibt nur noch eine
> Setup-Zeit zu beachten.

Dafür hätte ich gerne einen Beleg. Hast Du eine Quelle?

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mathi schrieb:
> Lothar Miller schrieb:
>> Die Haltezeit von FFs in aktuellen FPGAs ist 0ns. Es gibt nur noch eine
>> Setup-Zeit zu beachten.
>
> Dafür hätte ich gerne einen Beleg. Hast Du eine Quelle?

Schau ins FPGA Datenblatt

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
D. I. schrieb:
> Schau ins FPGA Datenblatt

ins = in das

Hat sich der Markt in den letzten Minuten so verdichtet das es nur noch 
ein FPGA gibt? ;)

Im Datenblatt des ECP3 sind 15ps angegeben. Und auch im Virtex5 
Datenblatt finde ich keine 0ns.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
> Damit verdoppelst du virtuell die Taktfrequenz. Denn im ersten
> Taktzyklus nach dem Reset steht nur die Hälfte der Zeit bereit, damit
> für die FFs bei der nächsten Flanke die Setup-Zeit eingehalten wird...

Das verstehe ich nicht. Wenn ich im Resetzustand bin, dann sollte die 
Schaltung (auch alle Flip Flops) irgendwann einen stabilen Reset-Zustand 
eingenommen haben. Den sollte sie erst bei der ersten Taktflanke nach 
dem Reset verlassen (da ja die FFs erst zu diesem Zeitpunkt neue Werte 
annehmen können). Das Wegnehmen des Resets zur fallenden Flanke sollte 
daher also nicht die Eingänge irgendwelcher Flip-Flops verändern können. 
Daher kann dann auch keine Setup-Zeit-Verletzung auftreten. Höchstens 
eine Verletzung einer einzuhaltenden Zeit zwischen Reset und erster 
Taktflanke (falls es die gibt. Hab ich mich aber noch nie drum 
gekümmert).

Und ich kann mich erinnern, daß mir der Xilinx Timing Report irgendwann 
auch mal Hold-Time Violations vorgeworfen hat. War aber auch ein 
freakiges ASIC-Design.

Autor: Konstantin L. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich danke euch für die Diskussion. Der kann ich zwar nicht ganz folgen, 
aber macht ruhig weiter - solche Diskussionen können ja auch einen 
'Klick' Effekt haben.

schönen Sonntag

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

Bewertung
0 lesenswert
nicht lesenswert
Hans schrieb:
>> Damit verdoppelst du virtuell die Taktfrequenz. Denn im ersten
>> Taktzyklus nach dem Reset steht nur die Hälfte der Zeit bereit, damit
>> für die FFs bei der nächsten Flanke die Setup-Zeit eingehalten wird...
> Das verstehe ich nicht. Wenn ich im Resetzustand bin, dann sollte die
> Schaltung (auch alle Flip Flops) irgendwann einen stabilen Reset-Zustand
> eingenommen haben.
Richtig: Alle Flipflops!!!
Aber wenn du einen kombinatiroschen Pfad (evtl. auch irrtümlicherweise) 
mit einem Reset versiehst, dann kommt mit oder ohne Reset was anderes 
raus. Und um diese Änderung zu berechnen hast du nur die halbe SetupZeit 
zur Verfügung.

Nimm nur mal das:
:
:
   mux_select <= externer_select when reset='0' else "111"; --- von hier

   process (reset, clk) begin
      if reset='1' then
         a <= "00";
      elsif rising_edge(clk) then
         if mux_select = "110" then                         --- bis hier nur halbe Setuptzeit
            a <= "01";                                      --- wenn Reset mit fallender Flanke inaktiv wird
         elsif mux_select = "010" then
            a <= b;
         :
         :
         end if; 
      end if;
   end process;


Mathi schrieb:
> Dafür hätte ich gerne einen Beleg. Hast Du eine Quelle?
Hier ein Spartan 3 (ds099):
Hold Times
TAH Time from the active transition at the CLK input 
to the point where data is last held at the F or G input         0 ns

Beim Virtex 5 ist es wegen der vielfältigen Möglichkeiten ein wenig 
schwieriger, aber dort finden sich sogar negative Hold-Zeiten :-o
Und dazu passend der Kommentar:
A Zero “0” Hold Time listing indicates no hold time or a negative hold 
time. Negative values cannot be guaranteed “best-case”, but if a “0” is 
listed, there is no positive hold time.

Es ist mir übrigens schon klar, dass es ein FF ohne oder sogar mit 
negativer Hold-Zeit nicht gibt. Solche Zeiten lassen sich mit 
Laufzeitunterschieden von den angegebenen Messpunkten bis zum 
eigentlichen Flipflop erklären. Wenn der Datenpfad länger ist, 
verschiebt sich das Validierungsfenster immer mehr in Richtung vor dem 
Takt.

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
> Hier ein Spartan 3 (ds099):Hold Times
> TAH Time from the active transition at the CLK input
> to the point where data is last held at the F or G input         0 ns
>

Danke schön!

Autor: Harald Flügel (hfl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Konstantin,

wenn Du schon einige Threds gelesen hast, dann hast Du sicher auch 
gemerkt, dass es in vielen Fällen die "one and only"-Lösung nicht gibt. 
So wohl auch bei der Frage nach dem Reset. Zunächst möchte ich Dir aber 
gerne, mit Verlaub, widersprechen:

Konstantin L. schrieb:
> Wie gesagt, ich habe riesige Verständnislücken das ist mir bewusst.

Das seh ich nicht so. Alleine die Formulierung deiner Frage zeigt, dass 
Dir vielleicht Erfahrung fehlt, aber nicht das nötige Verständnis. Und 
die Problematik des Reset wird nunmal von einigen Leuten unterschiedlich 
bewertet. Ich stimme Dir jedenfalls zu, wenn du meinst:

Konstantin L. schrieb:
> Dann wäre nach einem Reset alles im fpga wenigstens auf default
> Werten was für mein Gefühl irgendwie wünschenswert ist. Ich denke an
> Automaten, default Registerwerte usw. die doch zum Rest des
> zurückgesetzten Systems passen müssen.

Die Bedenken der meisten Antwortschreiber gehen in die gleich Richtung: 
Es darf nicht sein, dass durch ein irgendwie geartetes Signal an einem 
Reset-PIN des FPGAs dieses aus dem Tritt kommt. Und was ein prellender 
Taster für ein Signal abgibt, oder ein RC-Glied beim langsamen 
Durchlaufen der Schaltschwelle, das sieht oftmals gräulich aus. Ich habe 
mir daher meistens Filter in das Reset-Signal eingebaut. Etwa in der 
Art: Das Signal vom Reset-Taster (oder sonstwo her) muss mindestens n 
Takte lange aktiv sein, bevor es an die interne Logik gegeben wird. 
Gleiches für das Ende von Reset. Und das dann Ganze immer synchron.

Zuletzt noch meine Einschätzung zu deinem konkreten Fragen:

Reset würde von den Tools intern über ein reset Netz verteilt. ist das 
richtig? Die Tools denken inzwischen mit und verteilen Clocks, Resets, 
und weitere Signale mit hohem fan-out (= viele Benutzer) über spezielle 
Routing-Ressourcen.

Wenn das so ist sollte doch das Problem, daß die FF reset zeitlich 
extrem versetzt bekommen entschärft sein? Entschärft ja, weg nein.

Und einen noch so kurzen Puls bekommen doch trotzdem alle 
angeschlossenen FF irgendwann mit. Nee, leider nicht. Innerhalb des FPGA 
könnten tatsächlich einige Flipflops einen kurzen Reset übersehen. Die 
Welt ist leider nicht digital.

Wenn nach einem reset eine gewisse Zeit kein clk anliegt, gibt es dann 
Probleme mit nicht zurückgesetzten FF? Ein extrem kurzer Reset könnte 
eine Statemachine in einen Zustand bringen, aus dem es keinen Ausweg 
gibt.

Als gefährlich war ja auch das Szenario beschrieben wenn reset eben 
unmittelbar vor clk eintritt. Stoppt der reset Knopf den Takt - keine 
Probleme? Bis auf eben den Fall dass nicht alle Flipflops den Reset 
gesehen haben.

Sollte man dann ein reset Signal eintakten und im ganzen Design 
taktsynchron verwenden? Klares Ja.

Grüße, und viel Erfolg
Harald

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

Bewertung
0 lesenswert
nicht lesenswert
Harald Flügel schrieb:
> Sollte man dann ein reset Signal eintakten und im ganzen Design
> taktsynchron verwenden? Klares Ja.
Ein klares ja deshalb, weil jedes asynchrone Signal irgendeine 
Einsynchronisierung (oder Validierung) braucht. Und der Reset ist ja 
wohl das asynchronste Signal schlechthin.

> Als gefährlich war ja auch das Szenario beschrieben wenn reset eben
> unmittelbar vor clk eintritt.
Dieser Fall ist eigentlich ziemlich unkritisch. Wenn der lang genug 
anliegt, werden früher oder später alle FF den Reset gesehen haben (und 
bestenfalls währen der paar ps eine FSM den falschen Zustand 
dargestellen).
Kritischer ist das Verlassen des Reset-Zustandes. Denn wenn hier ein 
paar FFs einer FSM schon mit den von aussen anliegenden Signalen 
arbeiten, und andere noch für einen Takt im Reset-Zustand sind, dann 
läuft das Design nicht richtig an...
Das hört man dann auch immer wieder: "Mein Design startet manchmal nicht 
richtig. Aber wenn es läuft, dann tagelang problemlos."   :-o

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
> Aber wenn du einen kombinatiroschen Pfad (evtl. auch irrtümlicherweise)
> mit einem Reset versiehst, dann kommt mit oder ohne Reset was anderes
> raus. Und um diese Änderung zu berechnen hast du nur die halbe SetupZeit
> zur Verfügung.
Das ist aber nun allerschlechteste Designpraxis. Wer ein asynchrones 
Signal in dem kombinatorischen Signalpfad abfragt gehört geschlagen.
Aber es heißt ja auch Reset (also für Flip Flops) und nicht MUX-Select 
o.ä. Das asynchrone Reset-Signal hat also nur etwas an Flip Flops 
verloren. Und da funktioniert es einwandfrei (wenn entsprechend 
einsynchronisiert).

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

Bewertung
0 lesenswert
nicht lesenswert
Hans schrieb:
> Lothar Miller schrieb:
>> Aber wenn du einen kombinatorischen Pfad (evtl. auch irrtümlicherweise)
>> mit einem Reset versiehst
> Das ist aber nun allerschlechteste Designpraxis. Wer ein asynchrones
> Signal in dem kombinatorischen Signalpfad abfragt gehört geschlagen.
Richtig, ich schrieb: irrtümlicherweise. Das kann auch so entstehen, 
dass da mal ein registriertes Signal war, das aber nach Umschreiben 
irgendeiner Zeile auf einmal nur noch kombinatorisch ist.

Ge- und erschlagen wird er dann von der Realität... ;-)

Autor: NeunmalKlug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mathi schrieb
>ins = in das
>
>Hat sich der Markt in den letzten Minuten so verdichtet das es nur noch
>ein FPGA gibt? ;)

Immer schön Korinthenkacker spielen, aber nicht mal in der Lage sein, 
einen
deutschen Nebensatz richtig einzuleiten. (Hinweis: ,dass)

;)

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

Bewertung
0 lesenswert
nicht lesenswert
NeunmalKlug schrieb:
> (Hinweis: ,dass)
Das müsste eher ", dass" heißen, denn sonst gehts Richtung Plenken... 
;-)

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
NeunmalKlug schrieb:
> Immer schön Korinthenkacker spielen, aber nicht mal in der Lage sein,
> einen
> deutschen Nebensatz richtig einzuleiten. (Hinweis: ,dass)
>
> ;)

Wie ich sehe können wir beide das gut :-D

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.