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? :)
@ 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
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.
@ 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
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
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.
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)
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
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.
@ 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?iLanguageID=1&category=&sGlobalNavPick=&sSecondaryNavPick=&multPartNum=1&sTechX_ID=pa_metastability >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
@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!)
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.
@ 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
"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
@ 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
"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
@ 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
@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.
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
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.
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
@ 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
> 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.
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
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
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
@ 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?iLanguageID=1&category=&sGlobalNavPick=&sSecondaryNavPick=&multPartNum=1&sTechX_ID=kc_smart_reset MfG Falk
Falk Brunner wrote:
>http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?iLanguageID=1&category=&sGlobalNavPick=&sSecondaryNavPick=&multPartNum=1&sTechX_ID=kc_smart_reset
Guter Link!
Ich hoffe das Experten wie der Johannes Traxler (johnsn) hier auch
mitlesen.
Cheers, Roger
>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.
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
>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?
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
@ 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
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
@ 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
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
@ 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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.