mikrocontroller.net

Forum: FPGA, VHDL & Co. Nichtgetaktet immer schlecht?


Autor: Christian Peters (kron)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

folgendes Problem, ein Signal wird in einem von Clock 1 getakteten 
Prozess A erzeugt und soll in Prozess B etwas auslösen (Startsignal).
Prozess B läuft aber mit Clock 2, die etwas langsamer und nicht synchron 
zu Clock 1 ist.

Normalerweise würde ich das Signal halt nochmal mit Clock 2 takten,
aber dabei geht mir immer ein Takt verloren, was in dem Fall schlecht 
ist.

Ist es schlimm, wenn das Signal im Bezug auf Clock 2 ungetaktet ist?
Das Signal wird dort nur an einer einzigen Stelle verwendet (eben als 
Startsignal), und da gibt es doch eigentlich nur die Möglichkeit,
dass es bei der steigenden Flanke von Clock 2 schon da ist, oder eben 
noch nicht, dann kommte es bei der nächsten.
Kann es da trotzdem zu irgendwelchen Problemen kommen?
Wenn ja, zu welchen? :)

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Christian Peters (kron)

>folgendes Problem, ein Signal wird in einem von Clock 1 getakteten
>Prozess A erzeugt und soll in Prozess B etwas auslösen (Startsignal).
>Prozess B läuft aber mit Clock 2, die etwas langsamer und nicht synchron
>zu Clock 1 ist.

>Normalerweise würde ich das Signal halt nochmal mit Clock 2 takten,
>aber dabei geht mir immer ein Takt verloren, was in dem Fall schlecht
>ist.

Richtig, aber in diesem Fall praktisch unvermeidbar. GGf. kannst du 
tricksen und mit der jeweils anderen Taktflanke das Signal abtasten, 
dann sparst du 1/2 Takt.

>Ist es schlimm, wenn das Signal im Bezug auf Clock 2 ungetaktet ist?

Ja.

>Das Signal wird dort nur an einer einzigen Stelle verwendet (eben als

Denkst du! Sobalt es an mehr als EIN FlipFlop geht baust du dir den 
wunderschönsten mysteriösen Fehlergenerator. Den Fehler zu finden, HA! 
daran sind schon Generationen von Helden gescheitert.

>Kann es da trotzdem zu irgendwelchen Problemen kommen?

Sicher.

>Wenn ja, zu welchen? :)

Ein FlipFlop "sieht" das Signal als 1, ein anderes als 0. Deine 
State-Machine läuft in einen falschen oder gar illegalen Zustand. Und 
das aber nur 1 mal bei einer Millionen Takte. Viel Spass bei der 
Fehlersuche ;-)

MFG
Falk

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn das Signal nur an einer Stelle benötigt wird, kann es rein 
pegelgesteuert integretiert werden. Es muss dazu nur lang genug sein, 
d.h. auch dann muss die Relation >2:1 für die Perioden eingehalten 
werden. Wenn der langsame Takt inkusive Jitter und Unsicherheiten max 
10us sind, dann muss dein gebendes Signal >20us sein. Dann "sieht" dein 
Leseprozess eine Flanke. Wenn Dein reagierender Prozess aber 
flankegesteuert arbeitet, dann musst Du gfs die Länge des Signals 
begrenzen, damit es nicht mindestens einmal , sondern nur genau einmal 
gesehn wird.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jürgen ... (engineer)

>Wenn das Signal nur an einer Stelle benötigt wird, kann es rein
>pegelgesteuert integretiert werden. Es muss dazu nur lang genug sein,
>d.h. auch dann muss die Relation >2:1 für die Perioden eingehalten
>werden. Wenn der langsame Takt inkusive Jitter und Unsicherheiten max
>10us sind, dann muss dein gebendes Signal >20us sein. Dann "sieht" dein
>Leseprozess eine Flanke. Wenn Dein reagierender Prozess aber

Das allein ist NICHT ausreichend, um ein 100% sicheres Funktionieren der 
Schalttung zu gatrantieren!
MfG
Falk

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk hat Recht. Es können metastabile Zustände auftretten. Und dann 
sucht man echt sehr lange, eh man was gefunden hat. Dieses Thema ist bei 
mir eigentlich kein Thema mehr, ist halt verboten ;-) Wenn ein 
Fehlerfall nur ein Mal in 10-1000 Minuten auftritt, dann sucht man sich 
dumm und dämmlich. Ich habe schon ganze Designs umgeschrieben gehabt, 
bis ich endlich kapiert habe, dass man sowas nicht tun sollte ;-)

Grüße,

Kest

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein. Der anzunehmende metastabile Zustand existiert bei allen Signalen 
mit unbekannter Phase, die man erfassenw will. Irgendwann erwischt man 
den 1er Pegel, den man interpretieren möchte, egal ob man das einmal 
erfasst, oder mehrfach einsynchronisiert (was die Alternative wäre).

Erkennen wird man den Pegel also in jedem Fall, um darauf reagieren zu 
können, nur der Zeitpunkt ist nicht determinierbar. Das ist es aber bei 
einem Clockübergang oder einem externen Signals sowieso nicht.

Das Einsynchrionisieren ist nur dann erforderlich, wenn man einen 
Zeitbezug zwischen Signalen benötigt: Typisches Beispiel sind 
Datenbusse, bei denen ein enable interpretiert werden muss. Da nicht 
sicher ist, wann man das Signal erfasst, muss der zu diesem Zeitpunkt 
bestehenden Datenbus mit erfasst werden. Daher muss man es mindestens 
einmal über Register laufen lassen - bei jitterbedingten 
Phasenkonstellationen sogar zweimal.

Wenn man nur ein Signal hat, das nur an einer Stelle verarbeitet wird, 
braucht es keinen Zeitbezug.

Es muss nur daruaf geachtet werden, daß das Signal von der Periode her 
lang genug ist, oder anders herum gesehen, die samplende Periode kurz 
genug. Für die eine steigenden Flanke reicht "kleiner einfache Periode" 
für die fallende Flanke zusätzlich "kleiner halbe Periode". Der letzte 
Falle entspricht einem absampeln der Grundwelle des Rechtecks a la 
Shannon.

Autor: Christian Peters (kron)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für eure zahlreichen und ausführlichen Antworten!
Da in der RTL schematic rauskam, dass das Signal an drei Stellen 
anliegt,
habe ich in den sauren Apfel der Synchronisation gebissen. ;)

Aber ich will ja immer alles genau und prinzipiell wissen.
Deshalb frage ich erstmal, ob ich das mit Metastabilität richtig 
verstanden habe.

Metastabilität heißt, dass das FF "irgendwo" zwischen 0 und 1 liegt,
und dass ich vor allem nicht weiß, wo es liegt. Soweit richtig?

Dass das schlecht ist, wenn das Ausgangssignal des FF an mehreren
(wiederum miteinander zusammenhängenden) Stellen anliegt, ist klar.

Aber wie ist das im (jetzt ganz theoretischen Fall), wenn das Signal
wirklich nur an einer einzigen Stelle (z.B. eben als Startsignal für 
eine FSM) abgefragt wird?
Natürlich kann es sein, dass die FSM dann eine 1 sieht, wenn noch keine 
da ist.
Aber der metastabile Zustand tritt doch sowieso nur auf, wenn sich das
Eingangssignal ändert, oder? Wenn alles 0 ist, bleibts auch 0, stimmts?
So gesehen kann doch in dieser Konstellation nichts passieren, oder?
(Abgesehen davon, dass es insgesamt unsauber ist, ist rein prinzipiell 
gefragt)

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei zwei unterschiedlichen Clocks kann es passieren, dass während sich 
ein Signal ändert, dieser (mit der anderen Clock) irgendwo abgefragt 
wird, was genau zu Metastabilen Zuständen dann führt, weil es zu 
Schwingungen kommen kann (muss aber nicht).

@Jürgen:
du hast schon irgendwie Recht, den 1er Pegel wird man irgendwann 
erwischen. Dazwischen jedoch können sehr viele Schwingungen sein, wo die 
Statemaschine in irgnedein undefinierten Zustand springen kann (muss 
aber wieder nicht).

Ich habe vor einer Weile mit dem Spartan 3 Board ein schönes Design 
gemacht, wo ich die MEtastabile Zustände gezählt habe und über 
7seg-Anzeigen ausgegeben habe. Ich sage Dir, das waren nicht wenige :-/ 
Fazit war, sollten Signale abgetastet werden bzw. in andere Takt-Domäne 
überführt werden, müssen diese eingetaktet werden.

http://www.altera.com/literature/an/an042.pdf

Grüße,

Kest

Autor: Mark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

Ja, es geht nur um den Zeitpunkt wo sich das Signal ändert!
vielleicht sollte man einige Punkte nochmal genau definieren:
Zitat Jürgen:
'Wenn man nur ein Signal hat, das nur an einer Stelle verarbeitet wird,
braucht es keinen Zeitbezug.'

Bei diesem einen Signal handelt es sich um eine einzelne Leitung, die 
als Daten- oder Enablesignal verwendet wird, und zwar für genau 1 
Flip-Flop.
(Und das Signal darf niemals selbst als Takt verwendet werden!)

Sobald Du mehrere FFs dranhängen hast geht die Sache garantiert in die
Hose, weil die Laufzeiten zu den FFs im FPGA unterschiedlich sind.
Im Moment der Taktflanke kann es dann passieren, dass FF1 z.B. schon 
eine '1' sieht während FF2 noch 0-Pegel hat.
Das kann zu sehr interessanten Effekten führen, die man in der 
Simulation niemals sieht. Ursache ist im Prinzip die Verletzung der 
Setup-Zeit des Flip-Flops.
Es ist deshalb eine gute Idee, alle Signale die nicht synchron zum 
FPGA-Clock sind zunächst mal einzutakten. Bei jeder Designänderung 
müsste sonst geprüft werden, ob die Bedingung (s.o.) noch gilt oder 
nicht. Das kann sich aus zeitlichen und den schon oben genannten 
Fehlermöglichkeiten eigentlich keiner leisten.
Zum Thema metastabile Zustände findest Du sicher noch haufenweise Infos 
via googel.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jürgen ... (engineer)

>Das Einsynchrionisieren ist nur dann erforderlich, wenn man einen
>Zeitbezug zwischen Signalen benötigt: Typisches Beispiel sind

FALSCH!

>Wenn man nur ein Signal hat, das nur an einer Stelle verarbeitet wird,
>braucht es keinen Zeitbezug.

Das ist, wei bereits mehrfach erklärt, auch nicht korrekt. Durch 
laufende Wiederholung wird aus aus einer falschen Aussage noch keine 
richtige. Ok doch, das heisst dan Propaganda.

>Es muss nur daruaf geachtet werden, daß das Signal von der Periode her
>lang genug ist, oder anders herum gesehen, die samplende Periode kurz
>genug.

Reicht auch nicht.

>Falle entspricht einem absampeln der Grundwelle des Rechtecks a la
>Shannon.

Den guten Herrn Shannon hier anzubringen ist vollkommen daneben. Wir 
reden über Digitalsignale, nicht bandbegrenzte Analogsignale.

@ Christian Peters (kron)

>Metastabilität heißt, dass das FF "irgendwo" zwischen 0 und 1 liegt,
>und dass ich vor allem nicht weiß, wo es liegt. Soweit richtig?

Nein. Bei metastibilen Zuständen liegt der Wert praktisch auch auf 0 
oder 1, aber er ist eben nciht stabil. er kann jeden Moment kippen. 
Stabil ist er erst nach ein paar Nanosekunden. Und theoretisch wird er 
nie stabil, allerdings sinkt die Wahrscheinlichkeit, dass er nochmal 
kippt exponentiell.

http://www.xilinx.com/xlnx/xweb/xil_tx_home.jsp
http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp...

>Aber der metastabile Zustand tritt doch sowieso nur auf, wenn sich das
>Eingangssignal ändert, oder? Wenn alles 0 ist, bleibts auch 0, stimmts?

Sicher. Aber Signale ändern sich nunmal. Wenn nicht wären es ja 
Konstanten ;-)


MfG
Falk

Autor: Christian Peters (kron)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Falk: Ok, aber wenn das Signal so wie in meinem Beispiel als 
Startsignal (und NUR dafür) verwendet wird, ist das doch nicht 
problematisch.
Sobald das Signal einmal auf 1 ist, läuft die FSM los, danach wird ja 
das Signal nicht mehr überprüft, wie das dann zuckt, ist doch dann egal, 
oder?

(Das das generell eine zu vermeidende Sache ist, steht außer Frage, ich 
frage hier wie schon gesagt rein prinzipiell!)

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, also liege ich falsch oder ihr :-)

Im Prinzip ist so ein FF eine ziemlich analoge Schaltung, die eigentlich 
allen digitalen Designregeln widerstrebt. Aber so lange das Signal schön 
stabil ist, wenn der Tackt wechselt klappt es trotzdem.

Problematisch wird es, wenn das Signal gleichzeitig mit dem Takt 
wechselt. Denn dann wird das FF eben nicht am Ausgang eine klare 0 oder 
1 werden, sondern im analogen Bereich irgendwo dazwischen.

Das FF wird sich allerdings irgendwann für einen Wert entscheiden, wobei 
"irgendwann" in der Regel kleiner als eine Taktperiode ist.

Deswegen werden beim sauberen Einsynchronisieren zwei FF 
hintereinandergeschaltet, so dass das zweite FF beim Takten dann ein 
sauberes Eingangssignal hat, weil das erste (bzw dessen Ausgang) dann 
eingeschwungen ist.

Man kann sich das zweite FF sparen, wenn dahinter nur sehr wenige Gatter 
kommen, die die Zeit verkürzen, die das FF zum Einschwingen hat. Eine 
STM mit einer relativ unklaren Anzahl an Gattern erfüllt die Bedingung 
"sehr wenige Gatter" eher nicht. Deswegen sollte man das lassen.

Dazu kommt natürlich auch, dass es nicht so schön ist, wenn an dem 
gerade einschwingenden FF viele Eingänge in der Einschwingphase des FF 
einen Mittelspannungswert haben, bei dem beide Eingangstransistoren 
leiten und ziemliche Querströme entstehen.

Gruss
Axel
PS: "Einschwingen" mit Vorsicht geniessen, da schwingt natürlich nichts.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Christian Peters (kron)

>@Falk: Ok, aber wenn das Signal so wie in meinem Beispiel als
>Startsignal (und NUR dafür) verwendet wird, ist das doch nicht
>problematisch.

Wenn es WIRKLICH nun an ein FlipFlop ght, dann ja.


@ Axel (Gast)

>Das FF wird sich allerdings irgendwann für einen Wert entscheiden, wobei
>"irgendwann" in der Regel kleiner als eine Taktperiode ist.

Woher nimmst du diese Zuversicht. Und selbst wenn es so wäre, das Signal 
wird ja sinnvollerweise durch die nachfolgende Schaltung ausgewertet. 
Wenn da viel Logik benötigt wird braucht man viel Setup-Zeit . . .

>Deswegen werden beim sauberen Einsynchronisieren zwei FF
>hintereinandergeschaltet, so dass das zweite FF beim Takten dann ein
>sauberes Eingangssignal hat, weil das erste (bzw dessen Ausgang) dann
>eingeschwungen ist.

Stimmt, zu 99%. Aber auch der Ausgang des zweiten FlipFlops kann 
metastabil werden. Allerdings mit einer Wahrscheinlichkeit im Bereich 
von 1 mal in einigen Millionen Jahren.

>Dazu kommt natürlich auch, dass es nicht so schön ist, wenn an dem
>gerade einschwingenden FF viele Eingänge in der Einschwingphase des FF
>einen Mittelspannungswert haben, bei dem beide Eingangstransistoren
>leiten und ziemliche Querströme entstehen.

Das ist bei moderen FlipFlops kaum der Fall. Siehe meine Links.

MfG
Falk

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Woher nimmst du diese Zuversicht ?"

Ganz einfach. Die Zeit, die das FF zum Setzen braucht, hängt von der 
Technologie ab. Ebenso wie die übrlicherweise mögliche Taktfrequenz. 
Damit kann man bei einer gegebenen Technologie die beiden in Relation 
stellen.

" Und selbst wenn es so wäre, das Signal
wird ja sinnvollerweise durch die nachfolgende Schaltung ausgewertet.
Wenn da viel Logik benötigt wird braucht man viel Setup-Zeit . . ."
Nicht wenn man zwei FF hintereinanderschaltet zum Einsynchronisieren. 
Wobei zum vernünftigen Einsynchronisieren zwei FF benötigt, was wohl 
gerne mal vergessen wird.


"Stimmt, zu 99%. Aber auch der Ausgang des zweiten FlipFlops kann
metastabil werden. Allerdings mit einer Wahrscheinlichkeit im Bereich
von 1 mal in einigen Millionen Jahren."
Dann stimmt es aber eher zu 99,999999999999999999%. Also wohl annähernd 
genug 100% :-)

"Das ist bei moderen FlipFlops kaum der Fall. Siehe meine Links."

Sicher, aber nicht jeder verwendet 90 nm FPGA. Wobei, bei denen, die das 
tun, häufig auch wieder die Taktzeiten entsprechend kurz sind.

Davon abgesehen finde ich solche Tests mit denen die FPGA Hersteller 
ihre Produkte basierend auf irgendwelchen ausprobierten Dingen preisen, 
recht erheiternd. Denn was passiert, wenn die Temperatur am oberen 
Limit, die Spannung am unteren und das FPGA aus einer schlechten Charge 
ist ?  Mindestens für einen Serieneinsatz sollte man sich da mal 
Gedanken drüber machen. Wobei das natürlich von der Applikation abhängt.

Gruss
Axel

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Axel (Gast)

>Dann stimmt es aber eher zu 99,999999999999999999%. Also wohl annähernd
>genug 100% :-)

Ein Herzschrittmacher der zu 99,99% funktioniert läuft 53 Minuten pro 
Jahr nicht.

>>recht erheiternd. Denn was passiert, wenn die Temperatur am oberen
>Limit, die Spannung am unteren und das FPGA aus einer schlechten Charge
>ist ?

Du darfst davon ausgehen, dass das die Jungs von Xilinx, Altera und Co 
mehr als genug durchexerziert haben.

Und dein Ansatz, asynchrone Signale ohne Synchronisation zu benutzen, 
wird dich dem Ziel von Funktionssicherheit kaum näher bringen.

MfG
Falk

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Ein Herzschrittmacher der zu 99,99% funktioniert läuft 53 Minuten pro
Jahr nicht."

Deswegen schrieb ich ja 99,99999999999999999999999999999%. Was dann der 
von Dir genannten Wahrscheinlichkleit von 1 in 1 Mio Jahren entspricht.

"Du darfst davon ausgehen, dass das die Jungs von Xilinx, Altera und Co
mehr als genug durchexerziert haben."
Aus den verlinkten Seiten geht das jedenfalls nicht hervor.

"Und dein Ansatz, asynchrone Signale ohne Synchronisation zu benutzen,
wird dich dem Ziel von Funktionssicherheit kaum näher bringen."

Irgendwie scheinst Du meine Beiträge nicht zu verstehen. Ich habe mich 
massiv FÜR das saubere Einsynchronisieren mit zwei in Serie geschalteten 
FF ausgesprochen.

Gruss
Axel

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Axel (Gast)

>Irgendwie scheinst Du meine Beiträge nicht zu verstehen. Ich habe mich
>massiv FÜR das saubere Einsynchronisieren mit zwei in Serie geschalteten
>FF ausgesprochen.

Ohhh, Entschuldigung. Das war ja der Jürgen.

MfG
Falk

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Falk:

Du denkst mir etwas zu pauschal. Hier ging es um eine konkrete Aufgabe 
mit einer konkreten Lösung und das dazu von mir gesagte ist absolut 
richtig und wird nicht dadurch falsch, daß Du mit der Ungültigkeit im 
allgemeinen Fall argumentierst oder schlichtweg alles begründungslos 
verneinst.

>>Das Einsynchrionisieren ist nur dann erforderlich, wenn man einen
>>Zeitbezug zwischen Signalen benötigt:
>FALSCH!
Sehr wohl  Richtig! Es muss hier nichts "synchronisiert" werden, da es 
hier keinen Zeitbezug braucht! Es gibt auch hier - anders als im 
allgemeinen Fall externer Signale - kein Flankenproblem. Das Signal im 
konkreten Fall ist ein rein pegelgesteuert interpretierbares Signal. 
Solange der abtastende Takt schnell genug ist, wird dieser den 1er-Pegel 
mindestens einmal sehen. Daß es darüber hinaus noch zu weiteren 1ern 
kommen kann, oder auch gerade nicht, (ungünstiger Phasenbezug, 
wechselnder Pegel im Moment des Taktes) is vollkommen unerheblich. Wenn 
das FF aus 1 schaltet (warum auch immer) dann tut es das und wenn nicht, 
dann eben nicht. Es tut es aber mindestens 1x.

Wei gesagt lautete die Frage "Nichtgetaktet immer schlecht?)

>>Wenn man nur ein Signal hat, das nur an einer Stelle verarbeitet wird,
>>braucht es keinen Zeitbezug.
>Das ist, wei bereits mehrfach erklärt, auch nicht korrekt.

??? Das ist bereits aus rein logischer Sicht so! Wenn man etwas nicht 
braucht, braucht man es nicht. Es gibt nur ein Signal, ergo keinen Bezug 
zu irgendwelchen anderen Signalen. Wir reden wie gesagt von logischem 
Signalbezug. Ko konkrte gesprochen haben wir also ein irgendwann 
eintreffendes Signal, über dessen Zeitpunkt der Verarbeitung man eine 
ungefähre Aussage machen kann. Ohne Taktflankenbehandlung durch eine FSM 
wird es theoretisch bis zu 3x erkannt, mit eben nur maximal 2x.

> Durch laufende Wiederholung wird aus aus einer falschen Aussage
> noch keine richtige. Ok doch, das heisst dan Propaganda.

Durch pauschales Verneinen bringts Du kein Argument. Gewöhne Dir bitte 
an ,konkrete Aussage zu machen und sachlich zu antworten, dann weis man, 
was Du sagen willst.

>>Es muss nur daruaf geachtet werden, daß das Signal von der Periode her
>>lang genug ist, oder anders herum gesehen, die samplende Periode kurz
>>genug.

>Reicht auch nicht.

Wie ich oben beschirben habe, reicht es zu 100%. Notwendig und 
hinreichend. Wenn Du da einen Fehler siehst, müsstest Du ihn in der LAge 
sein, exemplarisch zu konstruieren, also aufzuzeigen, wann und unter 
welchen Umständen es " nicht reicht"

>>Falle entspricht einem absampeln der Grundwelle des Rechtecks a la
>>Shannon.
> Den guten Herrn Shannon hier anzubringen ist vollkommen daneben.
> Wir reden über Digitalsignale, nicht bandbegrenzte Analogsignale.

Du solltest eigentlich in der Lage sein, diese Analogie zu verstehen. 
(man beachte das Wortspiel :-) )

Digitale Signale sind nichts anderes als pegelorientiert interpretierte 
Analogsignale (Anstiegsverhalten unterdrückt), die zudem gerastert sind. 
Die Rasterung, die durch die Abtastung erfolgt, ist wiederum nichts 
anderes, als ein bandbreitenbegrenzendes Filter!

Das Abtasttheorem und die sich ergebenden Randbedingungen leiten sich 
mithin von genau dieser Vorstellung und Interpretation ab: Konkrtet muss 
von obigem Digitalsignal die Grundwelle erfasst werden. Das 
resultierende Signal ist ein technologieabhängig gerundetes 
Digitalsignal.

In der weiteren Betrachtung lassen sich Jitter und Pegelunsicherheiten, 
als einengendes Element auf den zu interpretierenden Pegel/Zeitpunkt 
werten und in einer resultierende Oberwelle überführen. Dies ist die zu 
erfassende Frequenz = Abtastfrequenz. Und wie ich anschaulich 
darstellte, benötigt man zum erfassen des positiven Flankenwechsels 
innerhalb einer Periode eine Frequenz mit minimal größer derselben, 
während man zum Erfassen beider Flankenwechsel zum zeitrichtigen 
Wiedergeben, mindestens das Doppelte braucht (jeweils auf die Perdiode 
des fokussierten Pegels bezogen). Im Falle einer Welle mit 50% d.c. hat 
man also genau den Grenzfall für Shannon/ Nyquist.

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin immernoch der Meinung, dass es ohne Synchronisation nicht geht. 
Die Aussage, dass das Signal nur an einer Stelle verwendet wird ist 
irrelevant. Und dass das Signal als Startsignal auch ruhig 
unsynchronisiert sein kann ist falsch!

Mal ein Beispiel: Frame Sync. Mit dem Signal wird z.B. nur eine 
Statemashine initialisiert, die Pixel zählt. So weit sogut, aber 
angenommen, dass die Statemaschine auch nur ein Mal pro 10 Sekunden sich 
verzählt, wie sieht es denn da aus? Die Bildausgabe ist gestört, das 
Bild zuckt und so weiter. Ich könnte jetzt weitere Beispiele bringen.

Das Problem ist, dass die Statemaschine zwar nur ein Mal gestartet wird, 
dies muss aber immer einen definierten Zeitbezug haben. Nicht in der 
Art, irgendwann mal nach dem das Startsignal auf '1' geht, sondern 
1,2,3...10 Takte, nach dem das Signal auf '1' geht. Im 
unsynchronisierten Fall ist die Aussage nicht möglich, weil eben sich 
das FF im metastabilen Zustand befinden kann.

Na ja. Es freut mich natürlich, dass so ein Fehler bei vielen selten 
oder gar nicht auftritt, aber mit der Diskussion möchte ich einfach auch 
zeigen, dass es gewaltig nach Hinten gehen kann :-)

Grüße,

Kest

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dies wäre dann eben ein solches Signal MIT Zeitbezug, wobei noch genauer 
betrachtet werden muss, auf welchen Takt sich der Begriff Synchronisatin 
bezieht. Beim Übergang von Taktdomainen hat man immer eine Unsicherheit 
von mindestens einem vollen Zieltakt, egal wie man es anstellt. 
Innerhalb der Zieldomain muss die Unsicherheit konkurrenter Signale mit 
Bezug natürlich Null sein. Nach Aussen, als auf den triggernden Takt 
bezogen, läßt sich das aber mit noch so vielen FF-Stufen nicht 
beseitigen, da ja genau die angenommenen metastabilen Zustände dafür 
sorgen, daß man nicht vorher sehen kann, wann die 1 nun wirklich 
durchkommt und wie oft. Die letzte wirkt ja faktisch als echter Start, 
wobei es Schaltungen gibt, die es nicht vertragen kur hintereinander 
zweimal gestartet zu werden.

Bei dem ganzen Thema gibt es eine ganze Reihe unterschiedlicher Fälle, 
die unterschieldiche Lösungen hinsichtlich Synchronsisation und 
Absampeln erfordern. Im Grunde sollte das aber im Rahmen des Studiums 
geklärt worden sein, WANN man WAS tun muss, um WELCHES Ergebnis zu 
erzielen, bzw. aus welchen Perspektiven man die Aufgabe sehen- und 
Fragen stellen muss, um die richtigen Schlüsse ziehen zu können. Bei uns 
zumindest war das damals so, daß das bis in den letzten Krümel 
durchexerziert wurde. Diese Dinge sind ja mithin nicht nur seit 
Erfindung der FPGAs ein Thema gewesen, sondern ziehen sich wie ein roter 
Faden druch die Geschichte der Digitaltechnik, wobei meine FPGAs und 
ASIC-Designs stets hervorragend liefen.

Autor: Roger Steiner (edge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen ... wrote:
> Es muss hier nichts "synchronisiert" werden, da es
> hier keinen Zeitbezug braucht!

> Dies wäre dann eben ein solches Signal MIT Zeitbezug, wobei noch genauer
> betrachtet werden muss, auf welchen Takt sich der Begriff Synchronisatin
> bezieht.

lies doch bitte mal den original post von Christian Peters, dann 
solltest du naemlich realisieren dass er ein asynchrones Signal in einem 
GETAKTETEN Prozess braucht.

> Es gibt auch hier - anders als im allgemeinen Fall externer Signale -
> kein Flankenproblem.

Ueberlege mal was ein externes und Christian's Signal gemeinsam haben.

> Das Signal im konkreten Fall ist ein rein pegelgesteuert
> interpretierbares Signal. Solange der abtastende Takt schnell genug ist,
> wird dieser den 1er-Pegel mindestens einmal sehen.

tja, nur sind die Zustandswechsel dieses Signals nicht synchron zu den 
lesenden Flip-Flops.

Gluecklicherweise hat Christian sein Problem ja nun mit synchronisieren 
des Signals geloest.

Cheers, Roger

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jürgen ... (engineer)

>Du denkst mir etwas zu pauschal. Hier ging es um eine konkrete Aufgabe

Sehe ich nicht so.

>mit einer konkreten Lösung und das dazu von mir gesagte ist absolut
>richtig

Sagt wer? Und sie dreht sich doch!

> und wird nicht dadurch falsch, daß Du mit der Ungültigkeit im
>allgemeinen Fall argumentierst oder schlichtweg alles begründungslos
>verneinst.

Bitte? Ich habe sehr wohl begründet, warum diese Methode unsicher ist. 
Und auch warum eben so ein Fehler verdammt schwer zu finden ist. Lies 
meine Postings nochmal.

>Richtig! Es muss hier nichts "synchronisiert" werden, da es keinen
>Zeitbezug braucht! Das Signal im konkrete Fall ist eine rein

FALSCH! Der Zeitbezug allein is NICHT das Killerkriterium! Es ist die 
Metastabilität UND Uneindeutigkeit, wenn ein asynchrones Signal ohne 
Synchronisation von mehr als einem FlipFlop (plus Logik davor) 
ausgewertet wird.

>pegelgesteuert interpretierbares Signal. Solange der abtastende Takt
>schnell genug ist, wird der den 1er-Pegel mindestens einmal sehen. Daß

Das reicht nicht.

>es darüber hinaus noch zu weieren 1ern kommen kann, oder auch gerade
>nicht 8ungünstiger Phasenbezug, wechselnder Pegel im Moment des Taktes)
>ins vollkommen unerheblich.

Ganz falsch.

> Wenn das FF aus 1 schaltet (warum auch
>immer) dann tut es das und wenn nicht, dann eben nicht. Es tut es aber
>mindestens 1x.

Du hast das Problem nicht verstanden. Lies meine Postings nochmal. Und 
schau dich mal im Internet um zum Thema asynchrone Signale und State 
Machines. Lass dir Zeit dabei.

>>Wenn man nur ein Signal hat, das nur an einer Stelle verarbeitet wird,
>>braucht es keinen Zeitbezug.
>Das ist, wei bereits mehrfach erklärt, auch nicht korrekt.

>wird es theoretisch bis zu 3x erkannt, mit FTM eben nur maximal 2x.

FTM?


>> Durch laufende Wiederholung wird aus aus einer falschen Aussage
>> noch keine richtige. Ok doch, das heisst dan Propaganda.

>Durch pauschales Verneinen bringts Du kein Argument. Gewöhne Dir bitte
>an ,konkrete Aussage zu machen und sachlich zu antworten, dann weis man,
>was Du sagen willst.

Muss ich mir nicht angewöhnen, das tue ich bereits. Wer aber konstant 
das lesen verweigert, und auch mit dem Verständnis so seine Probleme 
hat, soll bitteschön nicht mit dem Finger auf andere Leute zeigen.

>Wie ich oben beschirben habe, reicht es zu 100%. Notwendig und

Deine Meinung. Mehr nicht.

>hinreichend. Wenn Du da einen Fehler siehst, müsstest Du ihn in der LAge
>sein, exemplarisch zu konstruieren, also aufzuzeigen, wann und unter
>welchen Umständen es " nicht reicht"

Habe ich. Lies meine Postings.

MfG
Falk

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wer aber konstant das lesen verweigert, und auch mit dem Verständnis so >seine 
Probleme hat, soll bitteschön nicht mit dem Finger auf andere Leute

Der, der das Lesen verweigert, bis ja wohl Du.

>Lies meine Postings.
Mir Arroganz kommst Du bei mir nicht weiter. Lies Antworten erst mal 
selber, bzw schreibe was Sachliches und Vernüftiges. Du drückst Dich 
immer noch um das konkrete Beispiel herum, warum mein Beispiel falsch 
sein sollte, sondern wiederholst nur stumpf "es geht nicht, es geht 
nicht".

Auf solche Diskussionen habe ich jedenfalls keine Lust.

Wer sich nicht die Mühe macht, um im Detail eine Lösung zu sehen und 
konkrte Notwendiges von Pauschalem zu trennen in der Lage (und gewillt 
ist) der mag eben so entwicklen, wie er glaubt es richtig zu machen. Ich 
habe halt nur Tag für Tag die Lösungen der Pauschaldenker vor Augen und 
darf ihnen dann mit ModelSim oder auch dem Logicanalyzer zeigen, warum 
ihre Schaltung nicht soläuft, wie sie wollen.

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal ein Beispiel:

Das "Start"-Signal ist ein Reset-Signal, welches die Statemaschine 
initialisiert. Reset kommt asynchron rein, wird aber synchron 
ausgewertet. Und genau da haben wir jetzt den Salat. Jetzt müssen nur 
noch die Fehlzustände gezählt werden ;-)

Wird jedoch ein asynchrones Signal eingetaktet (mindestens 2 FF), ist 
der Startzustand der Statemaschine wohl definiert.

Sind wir uns da einig oder nicht?

Grüße,

Kest

Autor: Roger Steiner (edge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kest wrote:

> Das "Start"-Signal ist ein Reset-Signal, welches die Statemaschine
> initialisiert. Reset kommt asynchron rein, wird aber synchron
> ausgewertet.

Ideal um aus einer one-hot eine all-cold zu machen :-)

Cheers, Roger

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jürgen ... (engineer)

Jaja . . .

Autor: Volker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, verfolge die Diskussion mit Interesse, aber kann man das Beispiel 
von KEST auch einem Nicht-Profi wie mir etwas näher erklären?

>Das "Start"-Signal ist ein Reset-Signal, welches die Statemaschine
>initialisiert. Reset kommt asynchron rein, wird aber synchron
>ausgewertet. Und genau da haben wir jetzt den Salat. Jetzt müssen nur
>noch die Fehlzustände gezählt werden ;-)

Danke

Volker

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Volker (Gast)

>Hallo, verfolge die Diskussion mit Interesse, aber kann man das Beispiel
>von KEST auch einem Nicht-Profi wie mir etwas näher erklären?

http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp...

MfG
Falk

Autor: Roger Steiner (edge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
>http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp...

Guter Link!
Ich hoffe das Experten wie der Johannes Traxler (johnsn) hier auch 
mitlesen.

Cheers, Roger

Autor: Volker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Falk

vielen Dank.

Volker

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Mal ein Beispiel:
> Das "Start"-Signal ist ein Reset-Signal, welches die Statemaschine
initialisiert

Uff! ist es denn so schwer? Es kommt darauf an, wie Du das Signal in 
Deiner Zieldomain auswertest:

Wenn Du das startsignal nur an EINER Stelle abfragst und auswertest, 
KANN nichts auseinanderlaufen, da es keine zwei Dinge wie FFs, 
Kombinatorik, pipelines oder irgendetwas gibt. Wenn es keine zwei 
Elemente gibt, die das Signal "sehen" kann sich nichts verrennen.

Wenn Du aber eine statemachine resettest, dann bedienst Du u.U. mehrere 
FFs gleichzeitig. Je nach Codierung werden die dann auf 1 oder 0 
gehalten, bis sich das Signal ändert, oder sich Taktflanke und Signal 
ändern. Da hier die Laufzeitunterschiede wirken gehen diese FFs 
auseinander. Man muss hier eben "sehen", daß dies eine 
Multisignalinterpretaion ist, also parallele Architekturen darstellen 
(auch wenn es im HDL sehr eindimensional aussehen mag).

Vielleicht hilft es dem einen oder anderen, mal ein bischen was zu Löten 
und ein paar Gatter aufzubauen, möglichst aus Transistoren, um einen 
Zusammenhang zwischen den Prozessen und Beschreibungen in HDL und den 
realen Schaltungselementen und deren Funktion zu bekommen.

Autor: Roger Steiner (edge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen ... wrote:

> Wenn Du das startsignal nur an EINER Stelle abfragst und auswertest,
> KANN nichts auseinanderlaufen, da es keine zwei Dinge wie FFs,
> Kombinatorik, pipelines oder irgendetwas gibt. Wenn es keine zwei
> Elemente gibt, die das Signal "sehen" kann sich nichts verrennen.

die Abfrage ist syntaktischer Zucker, es ist die Reaktion auf das Signal 
was zaehlt. z.B die Statevariable einer Statemachine besteht meistens 
aus mehr als einem FF.

> Vielleicht hilft es dem einen oder anderen, mal ein bischen was zu Löten
> und ein paar Gatter aufzubauen, möglichst aus Transistoren, um einen
> Zusammenhang zwischen den Prozessen und Beschreibungen in HDL und den
> realen Schaltungselementen und deren Funktion zu bekommen.

Vielleicht solltest du dich mal von ModelSim und deinen Gattern loesen 
und einen RTL viewer konsultieren.

Cheers, Roger

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>z.B die Statevariable einer Statemachine besteht meistens aus mehr als >einem FF.

Prima! Das hast Du richtig erfasst. Genau dies steht auch als eine der 
genannten Möglichkeiten in meinem Text (nur so nebenbei gesagt). Und 
dort steht auch drin, daß dies eben genau KEIN Fall ist, an dem ein 
Signal nur an einer Stelle verarbeitet wird. Dies ist also KEIN 
Gegenbeispiel für den von mir kontruierten Fall, wo man nichts 
"Eintakten" muss.

Oh Heiland ...

>Vielleicht solltest du dich mal von ModelSim und deinen Gattern
>loesen und einen RTL viewer konsultieren.

Um bitte was zu sehen? Was zeigt der RTL-Viewer den anderes an, als die 
Gatter (und FFs) von denen ich mich lösen soll?

Und inwiefern kann man dort ein (anderes, als von mir beschriebenes) 
Timingverhalten erkennen?

Ist aber schon lustig, die Diskussion: Vor 20 Jahren Digitaltechnik 
gelernt, vor 10 Jahren den Studenten erklärt und nun kriege ich es 
selber wieder erklärt. Bin gespannt, was man mir als Nächstes 
erklärt....

Mal eine ganz bescheidene Frage: Was macht ihr eigentlich mit 
Adressbussen oder highspeed Datenbussen ? Taktet ihr das auch alles 
immer schon brav ein, damit es "synchron" wird?

Autor: Roger Steiner (edge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen ... wrote:
>>z.B die Statevariable einer Statemachine besteht meistens aus mehr als >einem 
FF.
>
> Prima! Das hast Du richtig erfasst. Genau dies steht auch als eine der
> genannten Möglichkeiten in meinem Text (nur so nebenbei gesagt). Und
> dort steht auch drin, daß dies eben genau KEIN Fall ist, an dem ein
> Signal nur an einer Stelle verarbeitet wird. Dies ist also KEIN
> Gegenbeispiel für den von mir kontruierten Fall, wo man nichts
> "Eintakten" muss.

Das war nebenbei das Problem von Christian. Weshalb propagierst du denn 
dagegen?

> Ist aber schon lustig, die Diskussion: Vor 20 Jahren Digitaltechnik
> gelernt, vor 10 Jahren den Studenten erklärt und nun kriege ich es
> selber wieder erklärt. Bin gespannt, was man mir als Nächstes
> erklärt....

Dir ist schon klar das

> mal ein bischen was zu Löten und ein paar Gatter aufzubauen,
> möglichst aus Transistoren,

sich nicht wirklich gut mit HDL vertraegt?

Das Geschick einen Gattersalat auf einem breadboard aufzubauen erweist 
sich als sehr hinderlich, wenns drum geht eine Schaltung in HDL zu 
beschreiben.

> Mal eine ganz bescheidene Frage: Was macht ihr eigentlich mit
> Adressbussen oder highspeed Datenbussen ? Taktet ihr das auch alles
> immer schon brav ein, damit es "synchron" wird?

In welcher Weise hat das mit dem hier diskutierten Thema zu tun?

Cheers, Roger

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jürgen ... (engineer)

>Ist aber schon lustig, die Diskussion: Vor 20 Jahren Digitaltechnik
>gelernt, vor 10 Jahren den Studenten erklärt und nun kriege ich es
>selber wieder erklärt. Bin gespannt, was man mir als Nächstes
>erklärt....

Manche lernens nie . . .  ;-)

>Mal eine ganz bescheidene Frage: Was macht ihr eigentlich mit
>Adressbussen oder highspeed Datenbussen ? Taktet ihr das auch alles
>immer schon brav ein, damit es "synchron" wird?

Aber sicher, das macht die ganze Welt so. Sogar recht erfolgreich. Warum 
glaubst du heisst _S_DRAM _S_DRAM?

MfG
Falk

Autor: Dirk S. (tomcat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
>>Mal eine ganz bescheidene Frage: Was macht ihr eigentlich mit
>>Adressbussen oder highspeed Datenbussen ? Taktet ihr das auch alles
>>immer schon brav ein, damit es "synchron" wird?
>
> Aber sicher, das macht die ganze Welt so. Sogar recht erfolgreich. Warum
> glaubst du heisst _S_DRAM _S_DRAM?
>

Ist das wirklich notwendig?
Aus meiner Sicht sind synchrone Designs doch auch über Chipgrenzen 
hinaus möglich. Die Setup- und Holdzeiten müssen halt eingehalten 
werden.
Ich würde das als einen der Vorteile bei SDRAM sehen, dass man darauf 
verzichten kann alles einzutakten wenn alles mit dem Systemtakt synchron 
läuft. (Nur meine Meinung, ohne praktische Erfahrung damit).

Dirk

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Dirk S. (tomcat)

>Ist das wirklich notwendig?

Was ist notwendig? Das Abtasten von Signalen? Bei synchronen Systemen 
manchmal, um die Taktfreqeunz zu erhöhen. Bei asynchronen System auf 
jeden Fall!

>Aus meiner Sicht sind synchrone Designs doch auch über Chipgrenzen
>hinaus möglich. Die Setup- und Holdzeiten müssen halt eingehalten
>werden.

Sicher, hat irgend jemand das Gegenteil behauptet?

>Ich würde das als einen der Vorteile bei SDRAM sehen, dass man darauf
>verzichten kann alles einzutakten. (Nur meine Meinung, ohne praktische
>Erfahrung damit).

Der SDRAM TUT alle Signale eintakten, ganz einfach um die maximale 
Geschwindigkeit rauszuholen. Stichwort Pipelining, das gilt auch 
zwischen ICs. Damit besteht die Datenübertragung zwischen ICs nur aus 
FlipFlop - Ausgangstreiber - Eingangsstufe - FlipFlop. Schneller gehts 
nicht. Der Preis dafür ist eine erhöhte Latenz, vor allem beim Lesen. 
Das wird aber durch Burst-Betrieb wieder ausgeglichen.

MfG
Falk

Autor: Dirk S. (tomcat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
> @ Dirk S. (tomcat)
>
>>Ist das wirklich notwendig?
> Was ist notwendig? Das Abtasten von Signalen? Bei synchronen Systemen
> manchmal, um die Taktfreqeunz zu erhöhen. Bei asynchronen System auf
> jeden Fall!

ja um was geht es denn hier, doch wohl um deine Behauptung, dass die 
ganze Welt Signale aus SDRAMs erst mal eintaktet um sie 
weiterzuverarbeiten.


>>Aus meiner Sicht sind synchrone Designs doch auch über Chipgrenzen
>>hinaus möglich. Die Setup- und Holdzeiten müssen halt eingehalten
>>werden.
>
> Sicher, hat irgend jemand das Gegenteil behauptet?

Ja, du.


> zwischen ICs. Damit besteht die Datenübertragung zwischen ICs nur aus
> FlipFlop - Ausgangstreiber - Eingangsstufe - FlipFlop. Schneller gehts
> nicht. Der Preis dafür ist eine erhöhte Latenz, vor allem beim Lesen.
> Das wird aber durch Burst-Betrieb wieder ausgeglichen.

Ich kann mir trotzdem vorstellen die Signale eines SDRAMs erstmal direkt 
auf Kombinatorik zu führen (z.B. einen Multiplexer) und dann erst wieder 
zu takten (sofern es die Setupzeiten eben zulassen).

Dirk

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Dirk S. (tomcat)

>ja um was geht es denn hier, doch wohl um deine Behauptung, dass die
>ganze Welt Signale aus SDRAMs erst mal eintaktet um sie
>weiterzuverarbeiten.

Das tut sie auch.

>> Sicher, hat irgend jemand das Gegenteil behauptet?
>Ja, du.

[ ] Du hast mich verstanden.


>Ich kann mir trotzdem vorstellen die Signale eines SDRAMs erstmal direkt
>auf Kombinatorik zu führen (z.B. einen Multiplexer) und dann erst wieder
>zu takten (sofern es die Setupzeiten eben zulassen).

Das tun sie aber nicht. Besorg dir den inneren Aufbau von SDRAMs und 
staune.

MfG
Falk

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.