Gut, also letztes Mal hatte ich ja eingeführt Schaltwerke,
Schaltwerke sind im Prinzip also Schaltnetze mit Rückkopplung durch die Rückkopplung,
kann es jetzt eben dazu kommen, dass die Schaltung eben schwingen,
irgendwelche meterstabilen Zustände erreichen oder im Idealfall, wenn sie sauber entworfen sind,
was da zum Beispiel bei diesen Rückgekoppelten nennt oder Norga dann immer der Fall ist,
ist Basis der S, Flipflop,
dass man dort dann eben stabile Zustände einstellen kann.
Damit lassen sich dann Jetzt im größeren Kontext, Schaltwerke,
im Sinne von endlichen Automaten aufbauen, wo man sagt,
ich habe Eingangsvektor, ich habe einen Ausgangsvektor,
ich habe dann eben eine Zustandsübergangsfunktion Wälder,
die aus aktuellem Zustand und entweder aktuellem Zustand und Eingang beim Midi-Automaten oder nur abhängig vom,
beziehungsweise Midi- und Moor-Automaten dann eben an Folgezustand errechnet und eine Ausgangsfunktion,
Lamda, die dann beim, das ist immer der Unterschied,
die dann beim Mili-Automaten abhängig von Eingangsvektor und aktuellen Zuständen.
Ausgangsvektor ermittelt beziehungsweise abhängig vom aktuellen Zustand, beim Ruhrautomaten
dann eben den Ausgangsvektor bestehen. Und in dem Rückkopplungsfahrt,
also sprich zur Speicherung der Information bzw. des Zustands in diesem Fall
, wären dann eben irgendwelche Flip-Flops eingesetzt.
Dort haben wir kennengelernt einmal pegelgesteuerte Elemente,
die jetzt so in Einfacher Form in Automaten erstmal nicht funktionieren,
weil ich da natürlich dann auch wieder Rückkopplungsschleifen habe.
Also Tagpegel gesteuert, der Flip-Flops oder auch kurz gesagt Ledges.
Und auf der anderen Seite haben wir Flanken gesteuerte Elemente.
Das ist dann das, was dort typischerweise einsetzt. Gut,
wenn man das jetzt untersucht und dort die Zeitbedingungen,
die da auftreten können, jetzt eben untersucht,
also jetzt gerade im Hinblick auf das,
was bei Flanken gesteuerten Elementen jetzt gelten muss in Bezug auf Wann
dürfen sich Eingänge relativ zum Takt bzw. relativ zur Taktflanke vorher das letzte Mal ändern?
Wie lange müssen Sie quasi stabil sein,
beziehungsweise ab wann dürfen sich nach der Taktflanke ändern?
Dann kommt man eben zu Setup- und Volt-Bedingungen,
beziehungsweise hat man dann eben entsprechend durch die Technologie irgendwo vorgegeben.
Und damit kann man dann ihm bestimmen, wie in einem System
letztendlich sowas wie maximale Taktfrequenzen sich ergeben beziehungsweise berechnet werden können.
Das war also im Prinzip Bart vermutlich vorgestern aufgehört habe. Ja,
zu dem Takten- oder Taktsignalen, also das,
was man meistens jetzt natürlich immer hat oder sich immer vorstellt,
ist also letztendlich sowas wie so ein rechteckiges Taktsignal, wie das hier angedeutet ist.
Im Prinzip kann man aber natürlich den Takt also auch beliebig so weit verschieben,
dass man da jetzt also quasi nicht identische Null und Einslängen hat,
sondern eben auch meinetwegen, wie jetzt hier angedeutet,
beispielsweise dann eben eine kürzere Eins-Phase.
Nicht das einzige, was also da dann eigentlich erst,
wenn man erzählt oder was man dann typischerweise betrachtet,
ist dann letztendlich die Tagperiode.
Gut, bei den Flip-Props, hatte ich gerade gesagt,
haben wir schon kennengelernt, die Pegelsteuerung,
wo im Prinzip dann der Taktpegel das Entscheidende ist oder eben die Flankensteuerung,
wobei man unterscheidet Forder- oder Rückflankensteuerung.
Daneben gibt es dann auch noch die Möglichkeit, sowas wie Mehrphasentakte einzuführen.
Damit lassen sich dann eben beispielsweise mit Ledges in Rückkopplungsphasen
dann eben auch Automaten aufbauen. So, hier ist nochmal
nur kurz beschrieben, also von der Idee her,
was also jetzt für die Pegelsteuerung entscheidend ist.
Also wenn ich jetzt, also zum Beispiel ist es ein
High-aktives Ledge habe, das dann eben quasi während der Takt.
Eins ist dann eben vorm Eingang zum Ausgang die Leitung durchgeschaltet werden,
bei Vorderflanken bzw. bei Rückflankensteuerung,
wie der Name schon sagt,
betrachtet man da dann eben immer
die Taktflanke
Wie gesagt, diese Unterscheidung zwischen Ledge und flankengesteuerten Elementen sollte man wissen,
hatte ich vorgestern ja auch schon an einem kleinen Beispiel mal
mit so ein paar Sachen durchgespielt, weil wie gesagt,
so was kommt dann also auch immer nochmal gelegentlicher an.
Gut, ja, Taktsignal. Als Informatiker denkt man natürlich
rein digital und wir stellen uns das Ganze dann natürlich irgendwo immer so vor.
Rein praktisch, hatte ich ja letztes Mal auch schon gesagt,
sieht das natürlich so aus,
dass ich also generell bei irgendwelchen Signalen, wenn ich irgendwo umschalte,
nicht unendlich schnell von 0 nach 1 oder von 1 nach 0 umschalte nicht.
Das heißt,
die Flanken sind dann eigentlich eher so ein bisschen schräg,
beziehungsweise man sich sowas ansieht
Zittert das, also elektrisch gesehen dann also doch immer relativ stark hin und her.
Also man hat häufig dann eben noch irgendwie solche Überschwinger,
dass das also entweder hier am Eins-Pegel oder auch am Nullpegel,
also nochmal deutlich rüber geht.
Und ansonsten ist das also auch alles andere als konstant.
Besonders deutlich wird das in dem,
was ja rechts drin zu sehen ist,
das ist jetzt wirklich vom Ostphiloskop,
also sprich elektrisch einmal an einer realen Schaltung gemessen.
In dem Fall,
das ist also auch schon ein bisschen länger her,
das Ganze dann abfotografiert
Und das, was man hier oben sieht,
das ist also PCI-Bus, ein 33-Megahertz-Tag. Und zwar,
dieses hier ist null, dieses hier ist eins und wie man sieht,
eine gewisse Periodizität lässt sich erkennen,
aber ansonsten hat das also mit diesem Rechteck, den wir,
das wir uns immer vorstellen, also nicht so sonderlich viel zu tun.
Da drunter sind also, sagen wir mal,
so zwei andere Taktsignale,
die dann also letztendlich mit Vorderflanke oder mit Rückflanke abgefragt werden,
die in diesem Fall dann also für ein Firewire-Protokoll genutzt wurden
Ja, wie gesagt, also da sieht man dann eigentlich
so sehr schön, wie sowas ein bisschen in der Praxis aussieht.
Das ist jetzt hier natürlich ein Extrembeispiel über eine selbstgebaute Platine.
Also wenn ich mir sowas jetzt also irgendwo im Rechner auf Motherboard ansehe,
da ist das schon ein bisschen solider aufgebaut.
Da schwingt das nicht ganz so viel auf der anderen Seite.
Da reden wir da auch nicht mehr über 33 Megaherz,
sondern über ein paar hundert Megaherz, die also dort noch irgendwo verarbeitet werden. Und auch da ist es dann so,
dass wenn man sich das also dann wirklich rein praktisch ansieht,
das Ganze, also teilweise wirklich auch eher irgendwie,
also gerade wenn ich jetzt sehr schnell an die Taktfrequenzen rangehe,
die maximal möglich, sie sind also eher irgendwelchen Sinuskurven gleich nach dem Motto,
es geht von 0 nach 1 und danach kann man dann gleich wieder umschalten von 1 nach 0,
das heißt also irgendwie so ein entsprechend starken oder stabilen Teil 1 oder 0 sieht man da dann also auch oft nicht.
Gut, das ist aber letztendlich dann jetzt natürlich das,
ich sag jetzt mal elektrotechnische Problem, was uns jetzt nicht weiter zu interessieren braucht,
nur dass man da also einfach mal so sieht in der Praxis,
was da eigentlich dann noch dahintersteht, dass die Wälder zumindest in dem Fall dann nicht so ganz digital ist.
Gut, ja,
dann hatte ich auch schon am Mittwoch gesagt,
dass bei Pegelsteuerung natürlich im Prinzip sowas wie ein Automat damit also nicht möglich ist,
weil natürlich, wenn ich jetzt also hier irgendwelche Rückkopplungen habe,
also sei das jetzt also hier irgendwie sowas wie ein Inverter oder sah das jetzt also irgendwie ein gesamtes Delta-Schaltennetz eines Automaten,
dann sieht das eben natürlich so aus,
dass wenn der Pegel 1 ist und das Ganze hier transparent ist,
dass ich dann also hier aufgrund der Verzögerungszeiten hier natürlich dann also auch irgendwelche Oszillationen habe.
Das heißt, damit lassen sich dann eben Automaten so erstmal nicht aufbauen,
was man machen kann,
ist im Prinzip ähnlich wie beim Übergang von Pegelgesteuerten auf flankengesteuerte Elemente,
dass man da dann so eine Art Master-Slave-Prinzip einbaut,
nämlich einmal ein nulltransparentes und einmal ein 1-1 transparentes Ledgen,
dann hat man letztendlich natürlich sowas dann also auch gemacht.
Rein praktisch wird man eigentlich direkt irgendwelche Flanken gestalten,
DFL-Flops an denen stellen wollen
Was man sonst auch häufig hat oder macht, sind dann also Mehrphasen-Takt-Systeme.
Also hier ist in so einem Beispiel zwei Phasen-Takt, dass man sagt,
okay, ich habe jetzt also ein Pegel gesteuertes Element.
Ich habe dann davon jetzt entsprechend zwei Stück,
also eben zwei beispielsweise D-Ledges und getrennte Takt-Signale,
4-1 und 4-2,
die dann wirklich des Jugend voneinander arbeiten,
wo man dann eben quasi bei der aktiven Phase von 4-1
dann eben bis zu dem zweiten Ledge entsprechend durchschalten kann.
Anschließend schaltet das erste ab und das zweite schaltet an und
dadurch hat man dann eben auch im Prinzip sowas aufgebaut.
Nicht rein praktisch sieht sowas so aus, dass man sich im Prinzip vorstellen kann.
Also ich habe einmal einen Takt, ich habe einmal sowas wie einen invertierten Takt.
So war es jetzt direkt mit einem Invertat herzustellen,
wäre ein bisschen schlecht, weil dann wäre da eigentlich nicht das Jugend,
weil ich dann also durch die Verzögerungszeit von einem Inverter dann also noch Bereiche bekomme,
wo sowas nicht ist, das was man eigentlich haben möchte,
ist etwas, wie dass er sie unten dargestellt ist,
wo ich dann also wirklich sehr schön voneinander getrennt hier die aktiven Phasen habe.
Und dann kann ich im Prinzip zwei solcher D-Ledges direkt hintereinander schalten.
Auch solche Taktszenale kann man also mit relativ einfachen Schaltungen,
so wie das hier angedeutet ist, sich erzeugen.
Gut, das eigentlich nur als Hinweis,
dass sowas im Prinzip machbar ist, wie die Schaltung aussieht,
müssen sie jetzt also nicht irgendwie für irgendwelche Produktmissionsaufgaben lernen.
Nicht, das gilt generell jetzt für irgendwelche Hades-Beispiele, die
hier gebracht werden. Da geht es jetzt nicht darum,
also hier irgendwelche abstrusen Skematics auswendig zu lernen und wieder runterzeichnen
zu können, sondern der Verstehen von Funktionsprinzipien.
Gut, ja, hier nochmal. Zwei Phasentaktis, also in dem Beispiel,
also haben wir eine harte Simulation, wie das Ganze dann aussieht.
Gut, auch das kann man entsprechend mit überschreiten. Gut,
ja, dann kommen wir jetzt eigentlich zu dem, womit ich dieses Kapitel angefangen habe, nämlich zu den endlichen Automaten bzw. zu Schaltwerken. Wenn es jetzt darum geht,
ich möchte einen endlichen Automaten haben,
der ein bestimmtes Verhalten realisiert, wie muss ich vorgehen,
um den jetzt also wirklich strukturiert zu entwerfen und damit um damit dann also im Prinzip meine Steuerung von irgendwelchen Abläufen zu machen,
beziehungsweise, also da werde ich gleich noch ein paar Möglichkeiten vorstellen oder Ideen vorstellen,
wofür man also generell solche Prinzipien braucht,
war also gerade so endlich Automaten sind wirklich ein,
zentrales Konzept bei wirklich sehr vielen Bereichen in der Informatik,
die jetzt also nicht zwingt,
was mit irgendwie diesen Low-Level-Beispielen hier aus Rechnerstrukturen zu tun haben,
sondern die begegnen uns also relativ häufig
Gut, ja, wie werden Schaltwerke überhaupt erst mal beschrieben
oder spezifiziert und anschließend dann natürlich, wie schaffe ich das,
die dann eben entsprechend sinnvoll zu entwerfen.
Dazu erst mal zwei Begriffe für die beiden Schaltnetze,
also im Prinzip des Zustandsübergangsschaltennetzes, Delta, beziehungsweise das Ausgabeschaltennetz Lamda,
stellt man nichts anderes erst mal als eine Funktionstabelle auf,
die heißen in dem Fall dann eben einmal Flusstafel,
eben als Beschreibung Zustandsübergänge und Ausgangstafel eben als Beschreibung des Ausgangsschaltennetzes.
Und dann kann ich also einen einfachen Automaten eben auch
direkt damit beschreiben. Hier als Trivialbeispiel, ein Automat,
der jetzt also irgendwie noch keine Eingabe hat.
Und zwar vier Zustände, die jetzt einfach erstmal nur der
Reihe nach durchlaufen werden. Und zwar soll das Ganze realisieren,
sowas wie eine Ampelschaltung in einem Einzustand, soll halt Rot an sein,
anschließend soll irgendwann mal eine Grünphase anbeginnen, also gehen rot und gelb an.
Anschließend habe ich hier meine Grünphase. Und bevor das Ganze
wieder rot wird, Kommt das berühmte gelbe Licht,
wo man also nochmal kräftig aufs Gaspedal tritt,
damit man auch noch rechtzeitig vor Rot über die harte Linie kommt.
So, also wie gesagt, das sind relativ einfache Automaten.
Macht jetzt so natürlich keinen Sinn, aber hierzwischen
müssen ja auch noch sehr viele unterschiedliche Zeiten vergehen.
Und im Zweifelsfall sollen auch noch eine andere Ampel geschaltet werden und
im Zweifelsfall soll vielleicht nur irgendwie so bei so einer Fußgängerbedarfsampel noch irgendwie gedrückt werden können und, und, und.
Aber um jetzt überhaupt erstmal das Ganze zu beschreiben,
würde jetzt hier aussehen, dass ich einfach sage, gut,
ich habe hier meine vier Zustände, die werden dann also einfach jetzt binär durchgezählt. Das heißt,
ich habe als Zustandsvektor zwei oder benötige ich dann dementsprechend zwei Bit,
Z1 und Z0, wo ich dann eben sage,
rot wird durch 0-0 kodiert, rot,
gelb, dann eben durch 0-1,
1-0 und 1-1. Denn dann kann ich eben sagen,
dadurch, dass hier Zustände ja nur direkt aufeinander folgen,
wie dass er sich an der Tafel skizziert ist,
dass ich an den Stellen dann eben entsprechend einfach sage,
das ist mein Zustand,
das ist mein Folgezustand.
Das mache ich dann entsprechend für alle Zustände. Damit habe ich
dann eben dieses Delta Charletnet komplett beschrieben. Und auf der anderen Seite kann ich dann eben auch,
wenn ich jetzt also quasi jede dieser Lampen quasi als einen Ausgang,
irgendwie so eines 3-Bit-Ausgangsvektors betrachte,
dann eben einfach direkt auch aus den jeweiligen Zuständen hier rauskodieren,
wo dann eben eine 1 dafür steht,
Licht ist an, null,
das Licht ist nicht an und dann kann ich das
eben für rot,
gelb und grün
entsprechend passend machen
So, das heißt,
da habe ich dann die entsprechenden Funktionstabellen und kann das machen.
Ja, das habe ich ja immer gesagt,
es gibt ja irgendwie diese zwei Arten von Automaten.
Was ist das für ein Automat? Mili-Automat oder Moorautomat?
Ah, die Pausenmelodie
Ja. Gut, ja, also Mili-Automat oder Moor-Automat.
Hat jemand Ideen, was das ist, was das sein könnte?
Bei Mili-Automaten ist der Ausgang von Zustand und der Eingabe abhängig.
Beim Moor-Automaten ist der Ausgang nur vorm Zustand abhängig
Wie sieht das hier aus? Ich habe es hier schon gehört,
Moore, weil ich habe hier gar keine Eingaben,
sondern der Reihe nachgehen einfach nur die Zustände ineinander über
und ich kann wirklich jedem Zustand,
was ja also auch in dieser Tabelle letztendlich hier ersichtlich ist,
eins zu eins dann eben die zugehörige Ausgangskodierung zuordnen.
Das heißt, das wäre dann sowas wie ein Moorautomat,
wie man das in dem Zustandsübergangsdiagramm dann nämlich auch noch sehr einfach sieht,
vor,
glaube ich,
auch jetzt
ein paar Folien später
Gut, ja, Zustandsdiagramm, das ist dann eigentlich,
also neben diesen Tabellen in der Regel,
wird dann also auch in den anderen Beispielen gleich noch folgen,
werden dann diese Flusstafeln und Ausgangstafel,
also auch in eine zusammengefasst, das heißt,
ich habe Zustand, die jeweilige Kodierung,
den Folgezustand und direkt dahinter dann eben auch nochmal die entsprechenden Ausgänge.
Gut, daneben auch eine Standardbeschreibung, eben solche Zustandsübergangsdiagramme,
wo man das Ganze dann eben entsprechend grafisch darstellt,
das heißt jeweils jeder stand,
wird dann dementsprechend als allen so ein Knoten gekennzeichnet.
Jeder Zustandsübergang dann eben entsprechend als Kante. Und was man dann eben hat,
ist, dass beim Moorautomaten die Belegung der Ausgänge,
weil sie ja nur von den Zuständen abhängig ist,
dann eben direkt an den Zuständen skizziert wird und ich dann eben an den Kanten irgendwelche Zustandsübergänge beschreibe.
Und beim Mili-Automaten habe ich in den Zuständen nur die Zustandskodierung
und beschreibe dann eben an den Kanten, sowohl Die Bedingungen,
unter deren Zustandswechsel stattfindet, als auch die zugehörige Ausgabe.
Das Ganze sieht dann typischerweise so aus, dass man eben sagt,
führen Moorautomaten, da hängen die Ausgangswerte immer nur vom Zustand ab.
In der Regel werden die deswegen dann auch immer direkt hier in
dem Zustand mit reingeschrieben, nicht das heißt ein Zustand,
beschreibt dann eben einmal irgendwie einen Namen oder die Kodierung des Zustands und eben die zugehörigen Ausgangswerte.
Und in den Zustandsübergängen habe ich, wie auch immer,
notiert, dann eben meine Bedingung.
Also hier haben wir so als Bulsche Bedingung, Also Ex-Royals stehen,
fakes ist gleich eins, nicht X an Impffix ist gleich null.
Oder eben wie in dem Fall ein unbedingten Zustandsübergang.
Das heißt, wenn ich in dem Zustand B bin,
ein Tag kommt, passiert eben der Zustandswechsel in diesen Zustand.
Was man dann in der Regel auch noch macht,
ist, dass man den Staatszustand irgendwie markiert.
Auch da gibt es dann je nach Autor oder nach Literatur
dann immer unterschiedliche Möglichkeiten, das zu machen. Also das,
was man einmal findet, sind also quasi immer irgendwie so
doppelt gezeichnete Kreise oder was man häufig auch hat, ist,
Das also hier in einem Kreis dann quasi irgendwie dann noch so ein Segment entsprechend eingefärbt wird.
Und dadurch weiß man dann eben auch nochmal hervorgehoben, dass es dann quasi der Startzustand des Automaten. Weil wie gesagt,
Startzustand, ich hatte bei den Philip-Plops auch schon gesagt,
also die haben häufig eben sowas wie ein Set oder Reset-Eingang nochmal zusätzlich,
brauche ich eben ja auch, um zu sagen,
was passiert nach dem Einschalten,
wie kriege ich das Ganze irgendwie initialisiert im Sinne der Automatentheorie,
geht es eben darum zu sagen,
okay,
ich starte in einem bestimmten Zustand und von da aus läuft das Ganze dann also irgendwie sauber los.
Das heißt, beispielsweise jetzt bei irgendwelchen Ampelschaltungen,
was ich natürlich dann also nicht irgendwie haben möchte.
Ich schalte das ganze System ein,
sämtliche Ampeln an sämtlichen Straßen sind erstmal irgendwie auf Grün geschaltet,
war es eigentlich sowieso nicht vorkommen sollte.
Und dann hat zumindest der Autoverwerter erstmal kein Problem. So,
ja, Moorautomat beim Mili-Automaten sieht das jetzt eben so aus,
dass man sagt, ich skizziere eben in einem Zustand letztendlich
nur den Namen oder eben eine Zustandskodierung.
Und an den Kanten habe ich dann eben die Bedingungen,
unter der der Zustandswechsel stattfindet. Und der Regel dann eben
mit so einem Slash einfach getrennt, die entsprechenden Ausgangswerte.
Und dadurch kann ich dann eben unterscheiden, dass,
wenn ich in dem Zustand A bin,
X ist gleich eins, soll das als Ausgang ausgegeben werden,
wenn ich in dem Zustand A bin,
X ist gleich null soll, das als Ausgang ausgegeben werden nicht.
Das heißt, dadurch sieht man eben in dem Automatendiagramm
auch direkt die Unterschiede zwischen Moor und Midi-Modell
entsprechend einfach
Gut, daneben gibt es da noch beliebig viel an,
Erweiterungen zu solchen Zustandsdiagrammen bzw. zu den Beschreibungen,
also eine der häufiger verwendeten Erweiterungen sind sogenannte Stageharts,
wurde von David Harrell 1984 im Prinzip eingeführt.
Da hat man dann die Möglichkeiten, auch noch sowas wie komplexe Hierarchien zu beschreiben.
Es gibt da die Möglichkeit, dadurch dann eben so was wie Unterautomaten zu beschreiben.
Es gibt die Möglichkeit, Nebenläufigkeiten zu beschreiben, also sprich,
dass mehrere Automaten letztendlich parallel und gleichzeitig irgendwie arbeiten.
Und es gibt eben auch sowas wie Timer. Das ist also eine Spezifikation,
also obwohl das ein Vergleichsweise alt ist,
wird das also auch heute immer noch relativ häufig benutzt, teilweise eben für komplexere Automaten, beim Entwurf von eingebetteten Systemen ist Wurst häufig mit drin. Und ja,
Beispiel wäre zum Beispiel sowas,
das ist ja so aus dem Originalpaper von Harley,
wo im Prinzip mit den Möglichkeiten hier so eine,
nicht damals übliche, einfache Digitalarmbanduhr beschrieben wurde, nicht,
wo ich also letztendlich hier irgendwie so meine drei Tasten habe und damit also irgendwie einstellen kann,
nicht wie komme ich in den Modus,
Alarm ist aktiv,
wie stelle ich eine Alarmzeit ein und so weiter und abhängig von Tastendrücken habe ich dann eben letztendlich ja immer irgendwelche Zustandsübergänge und das lässt sich dann eben sehr schön beschreiben und eben solche Sachen,
wie ich bin in dem Modus Alarmzeit soll eingestellt werden,
ich bin in den Modus Zeit soll eingestellt werden oder ich bin in dem Modus
Das Ding läuft einfach so vor sich hin. Das wären dann eben unterschiedliche Teilautomaten,
die man dann eben ganz gut in so einer Hierarchie,
was dann also hier durch diese unterschiedlichen Kreisgruppen dann gekennzeichnet ist, also irgendwie beschreiben kann.
Also wie gesagt, das ist eins der prominenteren Beispiele. Ja,
ansonsten hatte ich ja schon gesagt,
ähnliche Automaten ist wirklich so eins der Standardkonzepte in der Informatik,
wird eben in sehr vielen Sachen benutzt,
weil man damit eigentlich sehr gut irgendwie so zeitliche Abfolgen von Systemzuständen beschreiben kann,
weil man damit eben auch sehr gut beschreiben kann,
wenn ich es irgendwie sowas wie ein reaktives System habe,
wie geht das mit irgendwelchen Ereignissen um?
Nicht, was passiert, wenn die Taste gedrückt wird,
was passiert, wenn die und die Zeit abläuft?
Welche Folgen von irgendwelchen Aktionen werden irgendwie ausgeführt? Und wie gesagt,
das wird eben sehr teilweise eben auch so ein bisschen Hardware-nah natürlich benutzt.
Also jetzt irgendwie so bei eingebetteten Systemen bei Echtzeitsystemen wird aber eben auch als Beschreibung relativ häufig benutzt,
um einige formale Sachen zu beschreiben oder um gerade sowas wie Protokolle,
die zwei Rechner oder zwei Geräte irgendwie miteinander kommunizieren,
dann lässt sich das also zum Beispiel mal sehr schön in irgendwie so Automaten packen,
wo man sagt, nicht, also der eine Automat sendet,
also irgendwie eine Anfrage an den anderen.
Nicht dann läuft ein Timer los,
der wird dann mit irgendeinem Eck Knowledge oder irgendwelchen Datenwerten zurück antworten,
wenn das nicht innerhalb einer bestimmten Zeit passiert,
wenn die Antwort irgendwie falsch ist,
nicht dann muss der Sender darauf reagieren,
solche gegenseitigen Abhängigkeiten lassen sich eigentlich sehr gut in Automaten packen,
wenn ich deswegen hier also noch mal einige Beispiele,
die es also hier außerhalb von dem Kontext von Rechnerstrukturen sind.
Also zum einen findet man das teilweise in der Theorie Wenn
ich zum Beispiel sowas wie ein Pasa habe für irgendwelche Folgen von Symbolen,
also die Erkennung des Worts A, B, A,
dann sieht das so aus, dass ich,
also hier ist es mit den doppelten Kreisen übrigens nicht die Initial, sondern der Endzustand.
So, dann sieht das aber so aus, dass ich sage,
ich starte hier im Zustand S.0. Nicht wenn dann wird,
wenn ein A gelesen wird, der Zustand S.1 erreicht,
wenn ein B gelesen wird, der Zustand S.2 und wieder ein A,
dann habe ich das Ganze richtig erkannt.
Dann würde hier jetzt
irgendeine Ausgabe erfolgen
Wenn das nicht der Fall ist,
ich also entweder am Anfang Symbol B lese oder hier
eine Folge AA oder hier eben eine ungültige Folge,
dann lande ich eben mit irgendeinem Fehlerzustand, S4,
der mit dem Benutzer dann sagt, funktioniert nicht.
Also so kann man zum Beispiel sehr einfach auch irgendwie ein paar Sachen für Grammatiken schreiben,
fort im Prinzip dann also auch immer so einen internen Zustand, Automatenmodell.
Anderes Beispiel auch was völlig anderes, Game Design.
Kann die entsprechend abgelesen werden. Also Wir haben hier also
irgendwie so unseren beliebten Shooter, irgendwelche Gegner laufen haben und da durch die Gegend.
Jeder von denen ist irgendwie durch einen Automaten letztendlich programmiert oder skizziert und was passiert.
In der Regel läuft er also irgendwie munter durch die Gegend.
Wenn ich als Spieler in der Nähe bin, dann versucht er mich anzugreifen.
Und wenn der Spieler jetzt also nicht in der Nähe ist,
wie gesagt, läuft er weiter durch die Gegend,
wenn bei dem Angriff ich jetzt also irgendwie bösartig anfange,
zurückzuschießen und der Gegner jetzt verwundet wird und ein bisschen schlauer ist,
dann versucht er entsprechend erstmal abzuhauen,
beziehungsweise wenn sein eigenes Leben entsprechend schlecht ist,
irgendwo das berühmte Mad-Kit zu finden und so weiter und dann läuft das Ganze eben entsprechend weiter.
Also wie gesagt, das ist jetzt natürlich ein bisschen an den Haaren herbeigezogen,
war irgendwie so ein Beispiel, aber da sieht man eigentlich sehr schön,
wie eben auch solche Sachen oder Verhaltensweisen von irgendwie autonomen Agenten,
sage ich jetzt mal, in so einer Automatenbeschreibung letztendlich reingehen.
Andere Sache, das ist etwas, was Wir,
also Terms machen wir ja so im Robotik, da gibt es dann eben auch sowas,
wo man also relativ häufig irgendwie so kleinen Serverarchitekturen hat.
Es gibt also irgendwie einen Server, der hat eine zentrale Aufgabe,
soll irgendwas machen, dann habe ich dann eben unterschiedliche Clients,
die also irgendwie was tun und eine,
der Beispiel Aktion oder Automaten ist dann eben im Prinzip auch aus so einer vorgegebenen Bibliothek,
Actionlip, das Verhalten, Server oder kleinseitig,
wo man dann jetzt eben sagt,
das Serverseitig wird also beispielsweise jetzt irgendeine Aktion ausgegeben,
ein Goal, dann wird eben geguckt,
das schicke ich dann also zum Client.
Entweder es wird akzeptiert, dann ist das für mich aktiv. Oder wenn nicht,
läuft das eben hier noch in der Warteschlange oder der Client sagt,
oder aus irgendwelchen Gründen, es wird zurückgenommen und so weiter.
Und genau das Gleiche kann man dann eben auch irgendwie auf
der kleinen Seite machen, wo dann eben unter bestimmten Bedingungen,
wenn da jetzt also quasi so ein Goal bekommen hat,
soll das abgebrochen werden?
Ist das in der Warteschlange, ist das aktiv?
Unter bestimmten Bedingungen soll da jetzt also irgendwas passieren und so weiter.
Also gerade auch solche Sachen mit verteilten Beschreibungen hier, wie gesagt,
schon etwas detaillierter lassen sich dann eben entsprechend sehr gut in solche Automaten reinbringen.
Das, was wir eben hatten, die Stage-Charts,
auch das gibt es immer noch in irgendwelchen Standardprogrammierbibliotheken mit drin.
Also zum Beispiel Boost ist also eine Sammlung von diversen Algorithmen
mit unterschiedlichem Fokus, sei das jetzt also irgendwie schnelle Verarbeitung
von bestimmten Datentypen
Und so weiter und unter anderem gibt es dann eben auch eine Bibliothek,
die dann also letztendlich genau solche Stage-Charts implementiert und so weiter.
Also das ist jetzt hier ein Ausschnitt aus einer Beschreibung dazu,
wo also als Beispiel dann so eine Digitalkamera dann eben auch jetzt über Stage-Charts beschrieben wird,
nicht wo ich dann sagen kann, soll ein Bild aufgenommen werden,
nicht dann bin ich hier in dem Zustand Shooting,
wo dann also letztendlich fokussiert wird,
wenn das entsprechend in Ordnung ist, das Fokussieren nicht,
dann wird also letztendlich das Bild aufgenommen,
gespeichert.
Wenn ich jetzt also nicht in einem Zustandshooting bin,
dann gibt es hier eben entsprechende Eingaben, die dann eben sagen,
ich bin ein Idon und ein Sonstiges.
Also wie gesagt, das nur als Beispiel für solche Automatenbeschreibung.
Auch sowas lässt sich dann generell noch über beispielsweise
eine entsprechende grafische Editoren eingeben und beschreiben.
Also das ist ja dann auch so ein Beispiel in diesem Fall jetzt,
also über entsprechendes FWV-Fall, über entsprechende kommerzielle Werkzeuge,
wo man dann eben solche Automaten dann eben auch strukturiert entsprechend beschreiben kann.
Und wie gesagt, Standardkonzept in der Informatik lassen sich also
beliebig viele Beispiele finden. Und ich denke mir,
da werden sie also auch noch im Rahmen des Studiums dann einiges zu sehen.
Gut, wie gesagt, hier bei uns schalt Werke,
ist das jetzt natürlich nur so auf unterster Ebene vergleichsweise Hardware nah,
für eben solche einfachen Beispiele
wie sowas
Gut, generell hierzu auch noch mal so ein bisschen,
auch noch mal ganz kurzer Exkurs in Bezug auf,
wie beschreibe ich jetzt generell erst mal so ein bisschen Hardware,
beziehungsweise in diesem Feuer zu Schaltwerke, was man hier schon sieht.
Also eigentlich könnte ich solche Abläufe natürlich sinnigerweise irgendwie in Programme bringen.
Das heißt also, ich kann eben sagen, der Zustand
des Automaten wäre dann eben eine Variable. Dir gibt es dann einen Aufzählungstyp,
hat eben genau vier Werte und Dem kann ich jetzt eben der Reihe nahe,
je nachdem, wie ich das kodiere, dann eben irgendwas zuweisen,
abhängig von bestimmten Eingangsbedingungen, war sich dem dann eben entsprechend anderen wert zu.
Das wäre, also das führen das jetzt irgendwo in einer stinknormalen Programmiersprache programmieren würde, wenn man jetzt nicht schon irgendwelche vorgehenden Bibliotheken, also wie diese Boostsachen oder sowas benutzt. Ansonsten,
was gerade, wenn es jetzt also wirklich in die technische Realisierung in Hardware geht,
dann wird man also häufig mit irgendwelchen Hardware-Beschreibungssprachen arbeiten,
Hardware-Beschreibungssprachen muss man sich eben immer vorstellen,
ist im Prinzip also auch erstmal nichts,
sehr viel anderes als jetzt eine imperative Programmiersprache, weil,
gut, jetzt habe ich hier also irgendwie zwei Kapitel lang,
also irgendwelche Hardes-Sachen und Beispiele dazu vorgestellt,
wenn man sich aber eben anguckt, wie man jetzt letztendlich,
also irgendwie etwas größere und komplexere Systeme beschreibt und entwirft,
dann wird man das also nicht mit so einem Scamatic-Editor wie Hardes machen,
sondern Da hat man dann eben auch Beschreibungssprachen,
wo man also letztendlich sagt,
was soll das System tun?
Und hat dann eben ähnlich wie in der Programmierung,
wo ich dann mit einem Compiler das quasi in Assembler code
und dann also irgendwie ein ausführbares Programm übersetze,
hat man dort dann eben auch entsprechende Werkzeuge,
die dann also aus diesen Hardware-Beschreibungssprachen irgendwelche Strukturen aus Logikelementen,
also sowas wie einfachen Gattern, beziehungsweise eben irgendwie speichernde Elementen,
also Flipfloff, Solar,
Ledges,
automatisch umsetzen
Und jeweils, da kann man dann eben entsprechend sehr einfach das Ganze machen.
Hier nur ein Beispiel, also dass man sieht,
also wie so ein bisschen solche Hardware-Beschreibungssprochen aussehen.
Typischerweise hat man da immer eine Trennung zwischen einer Sicht nach außen,
also quasi ein Blackbox, sprich welche Signale gehen da rein?
Welche kommen da entsprechend raus? Und einer internen Realisierung,
was ich da dann also letztendlich tun soll,
in der Hardware-Beschreibungssprache Verylock, also ein D-Flip-Flop,
wäre letztendlich so beschrieben,
das nennt sich dann dort,
also Module
Wo ich also hier einmal sage, welche Ein- und Ausgänge gibt es
in dem Ganzen, wo soll irgendwo was gespeichert werden.
Und dann hat man in Hardware-Beschreibung Sprachen eben typischerweise die Möglichkeiten,
sowas wie Prozesse oder Code-Regionen zu beschreiben, wo nebenläufig sich irgendwo was tut. Das können sehr abstrakte Sachen sein,
also sprich, wenn ich sowas wie einen Prozessor habe,
CBU und Speicher, als zwei nebenläufige Teile,
die also unabhängig voneinander was tun, das können aber auch auf,
und dass da Ebene sowas wie einzelne Gatter sein,
also sprich, wenn ich sowas wie so ein Basis-RS-Flift-Drop habe,
Jedes nennt Gadda wäre dann quasi ein Prozess,
weil dann hat das natürlich unabhängig von dem anderen irgendwie schalten kann oder irgendwas tun kann.
Guten Very Lock wäre dann also quasi ein nebenläufige Anweisungsteil letztendlich,
so eine Always-Anweisung, wo ich da dann eben sage,
meiner Vorderflanke von der Clock oder im Reset soll beispielsweise hier irgendein,
beim Reset ein Wehr zurückgesetzt werden.
Ansonsten aufgrund hier der bulschen Bedingungen bin ich dann also hier
in dem Fall Taktvorderflanke soll der Datenausgang gleich den Dateneingang sein.
Damit habe ich letztendlich, also ab hier,
sowas wie ein Vorderflanken gesteuertes, D-Flip-Flop beschrieben in der Hardwarebeschreibungssprache VDL,
sieht das eben so aus, dass da es ein bisschen strukturierter.
Da habe ich also eine Trennung zwischen Blackbox-Beschreibung, Entity,
wo ich sage, Port, was geht rein, was geht raus.
Ich habe hier also quasi jetzt irgendwelche Bezeichner, meine Datentypen,
also Standard Logic ist sowas wie eine Art Bit,
habe dann hier als eine mögliche Realisierung dazu dann eben einen Prozess,
der quasi, wenn sich Reset oder Clock ändert,
aktiviert wird und der dann eben hier beim Reset das Ganze zurücksetzt bei einer Taktforderflanke von einer Clock, wird das Ganze gespeichert.
Und damit kann man dann also eben auch relativ einfach, also auch ein bisschen größere Sachen beschreiben. Ich war beispielsweise,
wenn ich hier an dieser Stelle habe, The Out,
zuweisungsfrei gleich DN, wenn ich da schreibe,
DN-Plus oder DN1 plus DN2 nicht,
dann habe ich da also im Prinzip vorausgesetzt,
der Datentyp ist da nicht mehr ein Bitbreit,
sondern also ein 32-Bit-Vector habe ich damit also letztendlich sowas beschrieben,
wie so eine Struktur, wo ich also sagen kann,
ich habe hier komplett Blödsinnsor.
Sowas wie eine Alu, also beispielsweise in diesem Fall jetzt
nur Addition und dann eben irgendwie ein entsprechendes Register direkt dahinter.
Nicht, das wäre dann die Out,
das wäre dann der eine und der andere Eingang und wie gesagt,
das lässt sich also letztendlich dann mit so einem Sechszeiler beschreiben.
Und hier kann ich natürlich noch beliebig viel an weiteren Funktionalitäten mit aufbauen,
sodass man damit dann also auch schon relativ schnell so ein bisschen größere Sachen mit beschreibt.
Was bei sowas dann eben auch immer noch wichtig ist,
also hier auch nochmal als kurzer Hinweis,
was dann ein bisschen die Schwierigkeit bei dem Ganzen ist.
Ich habe ja gesagt, diese Hardware-Sachen oder Hardware-Elemente tun ja irgendwie immer nebenläufig zueinander was.
Jetzt möchte ich das Ganze natürlich, und das ist im Prinzip,
das liegt also Hardes auch zugrunde, möchte ich das Ganze irgendwo simulieren.
So, das lasse ich jetzt also von irgendeinem Simulationsalgorithmus laufen,
der aber jetzt zwingend erstmal mit dieser zeitlichen Nebenläufigkeit nicht umgehen kann.
Sondern da wird jetzt eben irgendwie betrachten,
den Teil oder den Teil in einer beliebigen Reihenfolge.
Und da wird es jetzt eben erstmal schwierig, wann sollen,
wenn ich da jetzt also irgendwie 5000 verschiedene Gatte habe,
wann soll welches Gatter letztendlich von dem Simulationsalgorithmus angeguckt werden.
Dazu hat man dann eben hier dann bei diesem Always
immer so eine Bedingung, wo eben gesagt wird,
jedes Mal, wenn sich entweder Takt oder Reset ändert.
In VHDL ist das hier quasi diese Liste.
Dann muss der Simulator, diesem Prozess quasi durchrechnen.
Und okay, hier ist es jetzt natürlich nur ein Prozess.
Wenn ich jetzt ein gesamtgroße Schaltung habe,
dann sind da also mehrere tausende oder entsprechend noch mehr Prozesse.
Und dann wird also letztendlich darüber dann gesteuert,
waren welche Einheiten zu betrachten ist. Also wie gesagt,
das nur mal so ein bisschen zur Simulation des Ganzen.
Ansonsten, wie gesagt, Hardware-Beschreibungssprachen,
wenn wir jetzt hier nicht weitermachen,
aber dass man mal so grob so ein bisschen
schon mal was davon gehört hat
Gut, jetzt kommen wir aber wieder zu dem Thema zurück.
Wie entwerfe ich jetzt solche Schaltwerke? Und dazu kann man jetzt eben grob folgende Schritte unterteilen,
dass man sagt, also letztendlich fangen irgendwo natürlich an mit einer Spezifikation,
sah das jetzt also erstmal irgendwie die Textbeschreibung,
entwerfen Sie eine Schaltung, die das und das macht.
Oder natürlich schon ein bisschen anschaulicher, grafisch sowas wie so ein Zustandsdiagramm.
Nicht dann würde man damit jetzt sowas wie so eine Übergangstabelle raus kodieren,
vielleicht versuchen, die Annfall der Zustände noch ein bisschen zu minimieren,
weil häufig ist es so, also gerade auch in Textwellenbeschreibung,
dass man dann also irgendwie Mehrdeutigkeiten mit drin hat,
dass man also irgendwelche Sachen mit drin hat,
wo vielleicht Sachen unnötig beschrieben sind.
Okay, also bei solchen Trivialbeispielen wird das natürlich nicht sein,
aber wenn ich jetzt also wirklich ein bisschen komplexeres System habe,
dann möchte ich da natürlich versuchen,
das also möglichst kompakt oder eben auch übersichtlich
zu beschreiben
Anschließend würde man sich dann eben überlegen, wie kodiere ich die Zustände? Auch dazu folgt,
also auch jetzt in so einem ganz einfachen Beispiel, nochmal gezeigt,
wie sich also diese Zustandskodierung eben auch insgesamt auf die Schaltung auswirken kann.
Und nicht demzufolgert man dann, anschließend wirklich so eine Übergangstabelle,
wo dann eben, wenn die Zustandskodierung erfolgt ist,
natürlich ich dann wirklich schalt Funktionen, also sprich,
dass Deltaschalennetz direkt erstellen kann,
dann konnte man das Ganze dann eben jetzt wirklich minimieren,
so wie wir das vorher in dem Kapitel bei den Schaltnetzen gemacht haben und gegebenenfalls sollte man das Ganze hinterher dann eben auch noch mal entsprechend überprüfen.
Gut, Zustandskodierung, wie gesagt, das,
was einmal als erstes natürlich immer einfällt, weil man sagt,
gut, ich habe da jetzt also vier Zustände oder so und so viele Zustände,
dass ich die einfach irgendwie binär durchkodiere.
Dafür brauche ich dann natürlich minimal wenig Bits für meinen Zustandsvektor,
kann aber Manchmal vielleicht wieder ein bisschen schlecht sein,
weil Zustandsübergänge dann schwierig abzufragen sind und weil Ausgänge dann also teilweise auch ein bisschen schwierig abzufragen sind.
Deswegen machen an einigen Stellen dann eben sowas wie einschrittige Codes,
wie irgendwie solche komischen One-Hot-Kodierungen oder irgendwelche anderen Sachen da dann eben mehr sehen.
Wie gesagt, ich werde jetzt hier gleich noch mal mit
so einer Ampelschaltung drei unterschiedliche Varianten kurz zeigen, also auch zeigen,
was Vor- und Nachteile von den einzelnen Sachen sind.
Ansonsten möchte man natürlich sowas nicht zwingend selber und von Hand
machen. Das heißt also, irgendjemand gibt mir jetzt also
für so einen Automaten irgendwie so einen Zustandsübergangsdiagramm,
nennt die Zustände Z1, 2, 3, 4, 5.
Und ich muss mir jetzt auch nicht selber überlegen,
wenn ich jetzt Z1 als so und so Bit Vector kodiere,
kriege ich damit jetzt ein minimales Schaltennetz für meine Delta-Funktion
raus oder welche Eigenschaften hat das also hinterher.
Das heißt, an der Stelle hat man ja schon mal
sehr viele eigentlich Entwurfsentscheidungen zu treffen,
wie mache ich
diese Kodierung
Rein praktisch würde man das, also jetzt im Hardwareentwurf,
dann natürlich dann auch irgendwelchen Schar und Tools überlassen.
Das heißt, da habe ich dann eben auch irgendwelche Programme, die mir sowas machen.
Einen ganzen Satz von unterschiedlichen Varianten quasi durchrechnen und mir dann hinterher nur sagen,
okay, wenn das so und so gemacht wird,
ist das meinetwegen die kleinste Lösung oder ist das eben die schnellste Lösung?
Ist im Prinzip ähnlich wie bei diesem Minimierungsproblem,
wenn ich jetzt unterschiedliche Adira-Typen habe, also ich möchte rechnen,
A plus B, mache ich das Ripple Carry,
mache ich das Carry Leck Look Ahead,
mache ich das als in Cary Select oder wie auch immer,
dass ich da einfach nur sage, okay,
Randbedingungen ist, das soll in einem System eingesetzt werden,
was mit der und der Taktrate läuft und vorausgesetzt,
ich erreiche diese Taktrate,
dann soll es eben möglichst klein sein.
Und im Prinzip bei Charlotte Werken gilt genau
das Gleiche mit in Bezug auf diese Zustandskoudierung.
Das heißt, da hat man dann eben auch entsprechende Programme,
die einem sowas ein bisschen automatisieren bzw. automatisieren sollen
Gut, ja, rein praktisch würde man sonst eben sagen,
ich stelle dann, wenn ich eine Zustandskodierung habe,
solche Funktionstabellen auf,
mache dann eben entsprechend meine Schaltnetzminimierung und gerade in solchen Funktionstabellen habe ich dann natürlich auch relativ häufig sowas wie Don't Care-Therme,
weil ich sagen kann, okay, also angenommen,
ich habe jetzt, also hier so eine Abelschaltung,
die ist also nicht vier, sondern meinetwegen sechs Zustände benötigt,
ich sage, das Ganze wird irgendwie binär durchkodiert,
dann habe ich natürlich logischerweise acht mögliche Kombinationen,
das heißt zwei von denen,
treten real nicht auf.
Genau sowas kann man dann eben in Schaltnetzminimierung,
dann eben durch Don Care erschlagen und dort dann eben gegebenenfalls also auch noch einiges verbessern.
Was man an der Stelle dann eben auch immer noch machen muss oder beziehungsweise auch machen sollte,
bevor man jetzt also überhaupt anfängt, also einen Automaten,
also jetzt wirklich in die unteren Ebenen hinein zu entwerfen,
ist, dass man eben guckt, in dem Zustandsdiagramm ist das widerspruchsfrei und es ist vollständig.
Was ist damit gemeint. Zum einen kann ich eben bei bestimmten Einbahngangsbelegungen letztendlich Kanten haben,
wenn die jetzt also abhängig von irgendwelchen Variablen sind, die sich vielleicht gegebenenfalls widersprechen,
dass das letztendlich sowas wie zwei Kanten theoretisch aktiv oder möglich wären.
Und jetzt ist eben die Frage, was ist es denn jetzt? Nicht wenn ich sowas habe,
also sprich angenommen,
ich hätte jetzt so einen Automaten mit Wo ich also jetzt von diesem Zustand aus,
mit einer Bedingung 1-0 hier hingehe,
ich mit einer Bedingung 1, don't care hierhin,
mit einer Bedingung null, don't care hierhin, nicht,
dann kann man also schon relativ einfach sehen,
diese Bedingung und diese Bedingungen sind identisch und ich bin in dem Zustand,
ja, was kommt jetzt als Folgezustand, der hier oder der hier.
Im Sinne der Theorie, das, was wir hier betrachten
, Habe ich an der Stelle einen Widerspruch?
Das Ganze sollte also so nicht funktionieren, kann ich so also technisch nicht umsetzen.
Im Sinne der Theorie sieht das natürlich so aus,
wir haben jetzt hier betrachtet deterministische, ähnliche Automaten.
Dieses hier wäre jetzt eine nichtdeterministische Automat, also sprich,
es gibt mehrere Möglichkeiten und das System kann sich mal so oder mal so entscheiden.
Gut, also wie gesagt, solche Widerspruchsfreiheit.
Auf der anderen Seite muss ich natürlich sowas wie Vollständigkeit haben,
also sprich, sind auch alle möglichen Varianten dort letztendlich möglich
Formal gesehen würde es da so aussehen, Vollständigkeit wird dadurch beschrieben,
wenn ich sage, ich habe eine Anzahl von P-Zuständen.
Ich habe im Zustandsdiagramm quasi immer meine Kanten,
also einen Übergang von Zustand I nach Zustand J,
unter einer Eingangsbedingung X,
das letztendlich dann für jeden Zustand zu überprüfen ist,
ob eben auch wirklich alle spezifizierten Eingangsbelegungen in Kanten vorkommen,
beziehungsweise formal gesehen
muss eben gelten für alle
Oder Verknüpfung von J gleich 0, bis zwar auch P minus 1,
H von IJ, von X ist gleich 1. Sprich,
wenn ich also hier sowas hätte und ich,
also beispielsweise diese Kante nicht habe,
dann ist jetzt also hier zum Beispiel nicht daran spezifiziert,
was passiert, wenn der Eingang,
der erste Eingang gleich null ist.
Also ich will das hier immer eindeutig machen.
So und jetzt habe ich hier also irgendwie Eingangskombination 0-
0 oder Eingangskombination 0-1,
dann wäre das jetzt nicht vollständig
Was man häufig natürlich hart in Automaten, die bleiben in
einem Zustand. Das heißt, da würde man,
zum Beispiel durch sowas wie ein Null- und Care sagen,
okay, das wäre dann eben letztendlich vollständig. So,
und diese Bedingungen, also genau dieser Ausdruck mit diesem,
oder hier gleich eins, wäre da nämlich letztendlich nichts anderes als die Oder-Verknüpfung dieser drei Therme.
Widerspruchsfreiheit wäre dann eben so, dass man also für jeden Zustand überprüfen muss,
ob eben alle spezifizierten Eingangsbelegungen auch nur genau einmal vorkommen.
In dem Fall muss dann eben letztendlich für alle Paare von Kanten formal gesehen überprüft werden,
wenn ich die jetzt jeweils mit einer Unverknüpfung verknüpfe,
sind die dann immer paraweise zueinander des Jugend bzw. man kann das,
Schaltalgebranche schon ausdrucken, dass sich die dann unverknüpfe,
das Ganze dann also entsprechend für Uder.
Und wenn das nicht gleich null ist, habe ich eben irgendein Paar gefunden,
was eben an der Stelle dann nicht ist, jung ist.
Rein praktisch, hier das Beispiel dazu. Also ich habe hier Zustand,
A, Übergang nach B, C und D,
nicht unter der Bedingung, X1, sondern nach B gehen,
X1 nicht nach D, X1 nicht und X0 nach C.
Wie sieht das aus mit der Vollständigkeit?
Da müsste ich jetzt also quasi diese drei Bedingungen oder verknüpfen,
Rechnerregen der Butschen Algebra, ist immer wahr, gut,
das heißt, das ist entsprechend vollständig, war der Widerspruchsfreiheit,
müsste man jetzt eben letztendlich
Entweder das Ganze dann, also paarweise miteinander untersuchen und dann eben entsprechend nochmal oder verknüpfen.
Hier ist es jetzt also erstmal nur einzeln paarweise miteinander, verknüpft.
Und da sieht man dann eben logischerweise, dass wenn X1,
X0 oder X1 nicht und X0 und X1 nicht,
sprich diese beiden Kanten, dass das natürlich nicht ist,
jungt ist, wird da wahrlich dann also letztendlich für XA als gleich 0,
X0 gleich 1,
beide Übergänge aktiv haben,
ist in dem Fall
also jetzt nicht widerspruchsfrei
Gut, ja, kommen wir jetzt zu den angekündigten, hochkomplexen Beispielen, Ampelschaltung.
Also ich habe jetzt hier nochmal irgendwie so einen Verkehrsamtel mit drei Varianten,
wo einfach mal so kurz gezeigt wird,
was die unterschiedlichen Auswirkungen jetzt von verschiedenen Zustandskodierungen sind.
Nicht dann werde ich noch ein bisschen was zu zählern sagen,
weil im Prinzip ein Zähler ist,
formal gesehen auch nichts anderes als ein endlicher Automat.
Da kann ich sagen, okay,
der zählt jetzt hier null, eins, zwei,
drei,
geht wieder nach null
Ist ein Automat. Also ein Trivialwahl, da habe ich jetzt erst mal keine Eingangsbedingungen.
Nicht also auch sowas kommt noch und da kommt nochmal ein etwas komplexeres Beispiel,
was ich jetzt hier also in den Foliensatzen nochmal drin gelassen hatte,
weil das findet sich also da nochmal so ein etwas größeres Beispiel dann also in dem Hades mit drin,
werde ich aber nur ganz kurz darauf eingehen,
was damit gemeint ist.
Aber da sieht man eigentlich ganz gut,
dass es da in dem Fall dann wirklich eine Korpelung von sehr vielen verschiedenen Automaten gibt,
die da jetzt also irgendwie so ein bisschen was machen.
Also Schadenwerksentwurf Ampel, Ausgänge, vier Zustände. Und ich
habe grundsätzlich erst mal keinen Eingang, sondern eben der Reihe nach einfach nur diese Zustandsfolge. So,
wenn ich das jetzt entwerfe, hat ja gesagt,
also diese sechs Schritte würde man jetzt dann natürlich also irgendwie
erst mal als erstes so was wie so ein Zustandsdiagramm aufzeichnen,
sich dann eben die Zustandskodierung überlegen für Delta und Lamda Schaltnetz,
Flusstafeln und Ausgangstafeln mit beschreiben, das Ganze dann minimieren und eingeben.
So, erste Variante, ich kodiere das Ganze binäre durch,
Würde dann eben entsprechend so aussehen, dass ich sage,
ich habe hier Zustand, Codierung und Folgezustand.
Also in dem Fall sind jetzt eben einfach nur die beiden Tabellen,
die also hier schon mal irgendwie drauf lagen, entsprechend zusammengefasst.
Nicht. Und dann kann ich sagen, okay,
ich kann jetzt eben wirklich direkt für jede Variable,
für den Folgezustand, also Z1 plus Z0 plus,
beziehungsweise für jede Variable der Ausgänge.
Im Prinzip hier eine Schaltfunktion rauslesen und die entsprechend minimieren
Was bei sowas auch noch wichtig ist, also auch nur als Hinweis,
weil das wird in Übungsaufgaben und ärgerlicherweise dann also auch teilweise in der Klausur immer gerne mal falsch gemacht,
ist, dass ich,
wenn ich hier so eine Beschreibung habe jetzt und es sich jetzt beispielsweise,
also dieses hier ist jetzt ein Moor-Automat,
aber wenn es sich um einen Mili-Automaten handelt,
dann habe ich Schön versenkt.
So, dann habe ich ja in der Regel folgende Situation,
dass ich sage, ich habe hier meinen Zustand.
Abhängig von irgendeiner Eingangsbewegung gehe ich jetzt hier in meinetwegen Folgezustand.
So, der ist jetzt beispielsweise kodiert als 0-
0. 0
Und das soll es also meinetwegen hier der Zustand 1-0 sein und abhängig.
Also wenn ich hier meinetwegen jetzt für X-1 Gleich Null habe,
dann soll als Ausgabe 1-1 erscheinen, wenn ich jetzt nicht X-1 habe, soll die Ausgabe meinetwegen 1-0 sein.
Was man Also wenn man das gar,
also das jetzt also jemals ein Beispiel für so ein einen Zustandsübergang ist,
also von irgendwie so einem Tal, so eines Media-Automaten,
wenn ich das Ganze jetzt hier in die Tabelle schreibe,
dann sieht das ja so aus, ich habe hier meinen Zustand 00,
bin also jetzt hier bei meinem Zustandswerk dort, Z1,
Z0 und sage jetzt abhängig von,
meinetwegen jetzt im Eingang X1, wenn der Eins ist,
gehe ich in den Folgezustand.
0-1. Und wenn der Null ist, das ist dieses hier,
gehe ich in den Folgezustand 1-0. So,
und was jetzt immer gerne mal, okay,
das ist letztendlich erst mal soweit offensichtlich,
war es jetzt aber gerne da falsch gemacht wird,
ist jetzt immer die Art und Weise, wie die Ausgänge an der Stelle beschrieben werden.
Weil Und da ist es immer so zu sehen,
dass ich quasi von dem Zustand habe ich ja dann hier
die Beschreibung der Ausgänge, also in dem Fall an den Kanten.
Und die gehören aber immer noch zu diesem Zustand logischerweise,
beziehungsweise in die entsprechende Zeile hier. Das heißt,
wenn der Zustand 0-0 ist, Eingang 1,
dann sagt dieses hier ja, soll der Ausgang 1-1 sein,
beziehungsweise in diesem Falle dann der Ausgang 1-0.
So, und was Das wäre jetzt der, in Anführungszeichen,
richtige Fall, was häufig leider passiert, ist,
dass diese Ausgangsbelegung dann quasi hier diesen Endzuständen zugeschrieben werden.
Das heißt, in der Zeile,
wo ich hier irgendwie die 0-1 habe,
taucht dann quasi diese 1-1 auf,
beziehungsweise diese 1-0 würde dann also diesem Zustand zugeordnet werden.
Also da muss man aufpassen, also es geht immer letztendlich
abhängig davon, welchen Zustand,
welchen Eingabe habe ich
Die Ausgabe, dass sich das also letztendlich da in solchen Tabellen
dann immer alles in eine Zeile zusammenfasse, aber die Ausgabe nicht.
Also dieses hier wäre dann falsch. Die Ausgabe dann nicht
an den Zielzuzustand quasi ranhänge. Ich war für den,
würde dann letztendlich ja wieder genau das Gleiche gelten.
Und so sind die Ausgaben dann also letztendlich immer irgendwie eins zu weit geschoben. Gut,
wie gesagt, also dazu werden uns oder werden dann also auch noch Übungsaufgaben folgen,
beziehungsweise es wird dann also ja auch noch Später,
beziehungsweise jetzt einmal vor Weihnachten, schon mal einen ersten Satz an Musterlösungen geben.
Also ich erstelle dann also auch immer nochmal komplett für sämtliche Übungsaufgaben Musterlösungen,
wo jetzt also nicht nur irgendwie das Endergebnis drinsteht,
sondern wo also in der Regel dann noch relativ länglich,
also nochmal ein bisschen der Rechenweg entweder drinsteht oder irgendwie eine Herleitung von dem Ganzen,
sodass man das dann eigentlich auch immer nehmen kann,
um sich das dann also gerade in der Prüfungsvorbereitung nochmal so ein bisschen als Material anzusehen,
durchzugucken, dass man dann eben sieht für den und den Aufgabentyp, würde ich dann eben so und so vorgehen.
Wie gesagt, also sowas wird dann eben auch zu endlichen Automaten auch nochmal kommen.
Da kann man das dann eben auch nochmal sehen.
Aber ich habe das jetzt eben hier nun mal explizit angesprochen,
weil das eben wirklich so eine Sache ist. Also gerade in Klausur,
man hat es eigentlich irgendwie richtig rausgelesen, irgendwie falsch eingetragen,
rechnet dann mit dem Falschen letztendlich weiter und das ist immer irgendwie so ein bisschen ärgerlich,
war in dem Fall dann wirklich vermeidbar.
Gut, kommen wir jetzt aber zu diesem Beispiel hier wieder zurück.
Also Ich überlege mir jetzt eine Kodierung,
in diesem Fall ist das einfach binär durchkodiert,
kann dann eben das Ganze in so einer Tabelle, die dann letztendlich Fluss und Ausgangstafel ist, zusammenfassen. So,
und aus der kann ich dann eben im Prinzip genau das,
was so vorher bei den Schaltnetzen gemacht haben,
hier meine Schaltfunktion rauslesen, beziehungsweise kann jetzt anfangen,
da irgendwie KV-Diagramme zu zeichnen,
Schleifen einzuzeichnen und kriege da jetzt also irgendwie mehr meine minimalen Funktionen hin,
in dem Fall ist das hier natürlich noch relativ einfach,
also aus den beiden Eingängen, Z1 und Z0 irgendwie direkt rauszulesen,
was man da jetzt hat und da dann eben die entsprechenden Ausdrücke sich jetzt hierfür Folgezustand bzw. für Ausgangsvektor zu machen.
Gut, das Ganze kann man dann eben,
was zumindest in Übungsaufgaben, vielleicht also auch nochmal gefordert sein könnt,
dann eben direkt also irgendwie ein HSA eingeben,
damit dann also auch nochmal simulieren, gucken, ob das Ganze dann wirklich richtig tut.
Da sieht man das dann eben wirklich nochmal rein praktisch
In dem Fall Wäre das jetzt also hier dieses Beispiel hier,
dieses hier soll dann eben auch so ein Reset sein,
nicht damit setze ich das Ganze dann eben quasi in meinen Startzustand zurück,
in diesem Fall jetzt also hier mit 0
-0 kodiert und habe dann hier mein Taktsignal,
das sind jetzt vorderflankengesteuerte Flipflops,
mit denen,
die dann eben entsprechend den Zustandsvariablen Z1 und Z0 entsprechen
Und dann sieht man eben das immer mit der Faktforderflanke,
das Ganze entsprechend durchschaltet und hiermit den Gattern sind dann eben die Zugehörigen.
Ausdrücke, dann beschrieben. Ja, zweite Variante,
die ist jetzt gar noch ein bisschen erweitert.
Da habe ich jetzt nämlich nicht nur vier,
sondern fünf Zustände, wo ich dann eben sagen kann,
okay, also wunderbar, nachts wird Energie gespart,
da sollen die Ampeln also komplett ausgeschaltet werden.
So in dem Fall wird der Zustand dadurch kodiert, dass die Ausgabe,
also sprich Wahnsinn, welche leuchten aktiv, eben den Zustandsbitz entsprechen.
Das heißt, da benutze ich jetzt nicht zwei,
sondern drei Zustandsbits, kann dadurch dann aber letztendlich,
nicht also Reset, also alles ausgeschaltet, rot,
rot, gelb, grün, gelb.
Hier jetzt also meine Folgezustände eintragen. Auf der anderen Seite
sind natürlich die Ausgangsfunktion ist quasi trivial,
weil die gibt es in dem Sinne nicht mehr,
sondern der Ausgang entspricht dann einfach ja direkt dem jeweiligen Zustandsbild.
Das heißt also, damit hat man eben erreicht,
dass diese Funktion Lamda in dem Fall trivial ist,
weil das einfach nur eins zu eins, also technisch gesehen hat.
Also eine Leitung ist, die da rausgeht und diese Tabelle
dann eben nur noch mit Zustand und Folgezustand ist.
Die Übergangsfunktion werden dadurch jetzt also natürlich ein bisschen komplizierter.
Also auch das könnte man jetzt, dass ich hier wieder
irgendwie ein Hades eingeben simulieren und so weiter.
Wunderbar, funktioniert dann also auch entsprechend nicht. Und in
dem Fall habe ich dann aber nur noch diesen zusätzlichen Effekt,
das nach dem Reset alles ausgeschaltet ist und das dann entsprechend dann also irgendwie da rein nach losläuft.
So, dritte Variante wäre dann sowas wie so eine One-Hot-Kodierung,
hatte ich also ganz am Anfang mal irgendwie so vorgestellt,
wenn ich gesagt habe, so unterschiedliche Kodierungen oder Beschreibungen,
One-Hot heißt, also in diesem Fall,
ich habe hier jetzt wieder ohne ausgeschaltet vier Zustände
Zustandskodierung ist ein Vier-Bit-Vektor, 3-0,
eine einzige 1 und in dem Fall wäre das dann eben so,
dass also beispielsweise dieser Zustand dann eben durch den Vektor 0-0-0-1 kodiert ist,
0-0-1-0,
0-1-0-0,
1-0-0-0 und so weiter.
So, das, was man damit dann hat,
ist, dass, wie gesagt, hier in der Tabelle,
wenn man sich anguckt, was also zwischen Zustand und Folgezustand passiert,
dass da eigentlich nichts anderes ist,
als dass sie in diesem Vektor eine einzige 1 habe,
die als Zustandsübergang letztendlich nichts anderes passiert,
als dass das geschoben wird in einem Vektor.
Das ist ja also nichts anderes als ein Linksschieben von einem
Zustand zu einem anderen. Ich brauche jetzt natürlich mehr D-Flip-Flops,
habe da also jetzt also mehr Aufwand,
um jetzt diese vier Zustandsbits irgendwie zu speichern, aber die Zustandsübergangsfunktion,
also die ist Delta, ist es letztendlich minimal.
Das heißt, bei so einer Kodierung habe ich jetzt eben was,
okay, das ist jetzt einfach nur ein Schieben im Register.
Ja gut, da passiert nichts wahr, dass es einfach nur irgendwie fest miteinander verdrahtet.
Das wäre dann eine Schaltung, die kann also maximal schnell getaktet werden,
weil da habe ich jetzt also zwischen meinem Zustands-Bit-Eingang und ein Zustands-Bit-Ausgang,
jetzt keine Logik mehr dazwischen.
Das heißt, da hat man also an der Stelle dann
eben für die Zustandsübergangsfunktion quasi eine minimale Lösung geschaffen. Und was man hier auch sieht,
also die Ausgangsfunktion ist bei solchen One-Hot-Kodierungen natürlich auch,
oder nein, trivial nicht, aber relativ einfach,
weil, wenn ich jetzt eben wissen möchte,
also gerade so beim Moor-Automaten Welcher Ausgang jetzt, welchen Zustand zugeordnet ist,
muss ich auch nur ein einziges Bit abfragen und nicht mehrere.
Nicht dadurch kann man dann eben sehr einfach sagen,
wenn jetzt also beispielsweise eine Lampe wie jetzt, also meinetwegen,
also grün eben nur in einem einzigen Zustand,
also irgendwo einmal aktiv ist,
dann muss ich dann eben auch nur entsprechend dieses eine einzige Bit,
wo das grün aktiv ist, also letztendlich abfragen.
Das heißt, da sind diese Funktionen dann eben auch sehr einfach.
Denn das wäre dann eben auch das entsprechende hartes Beispiel dazu. Gut,
also wie gesagt, da sieht man eigentlich jetzt, Selbst an so einem ganz einfachen, trivialen Beispiel, wie sich also die Zustandskodierung letztendlich auswirken können. Nicht,
dass man sagen kann, okay,
in der Regel mache ich ja auch so,
fängt man immer erstmal irgendwie an und sagt, naja,
wenn ich jetzt sowas entwerfen würde, die näher irgendwie durchzählen,
wenn ich jetzt also entsprechenden Entwurfswerkzeuge habe und das dann im ZASV automatisch durchprobiert wird,
ist es eben sinnvoller, vielleicht nur andere Varianten zu machen,
weil, wie man hier sehr schön sieht,
es gibt schnellere Lösungen, es gibt kleinere Lösungen,
Es gibt nicht die optimale Lösung, genau wie ich sagen kann,
okay, wenn ich eine Liste sortieren möchte, nicht,
dann gibt es nicht den einen Sortieralgorithmus,
sondern beliebig viele, okay, da kann man sagen,
es gibt dann immer noch die in Anführungszeichen Besten,
aber wie gesagt,
also gerade beim Hardware-Info fahrt man entsprechend viele Möglichkeiten.
Gut, ja,
hier ist das Ganze nochmal so ein bisschen zusammengefasst,
nicht, dass man sagen kann, okay,
abhängig von der Kodierung habe ich eben sehr unterschiedlichen Aufwand in
Bezug auf die Hardware unterschiedlichen Ergebnisse jetzt in Bezug auf die Performance und auch da möchte man das natürlich so ein bisschen automatisiert haben.
Und gut, wenn man die entsprechenden Werkzeuge hat,
das Ganze automatisch passiert, ist es ganz gut, sowas entsprechend zu machen.
Gut, ja, hier jetzt nochmal als Beispiel, ich hatte gesagt,
also im Prinzip ein Zähler ist eigentlich so rumgesehen auch nichts anderes als ein ähnlicher Automat.
Sprich so ein zwei Bezähler mit den entsprechenden Übergängen kann ich natürlich auch so als Zustandsdiagramm zeichnen,
ist also so rumgesehen, trivialer Automat,
dann kann ich das Ganze jetzt noch irgendwie beliebig erweitern oder hier nur als Beispiel, wie sowas aussieht.
Also wenn ich so einen Zähler mit eine Art, wie so eine Enable-Leitung habe.
Nicht, wo ich sagen kann, er soll zählen oder er soll nicht zählen. Also auch das ist formal gesehen ja da nichts anderes,
als dass ich sage, wenn er zählen soll,
eh gleich eins ist, laufe ich also hier zyklisch durch,
wenn eh gleich null ist, verbleibt er hier in diesem Zustand,
kann ich dann eben auch im Zustandsdiagramm beziehungsweise in so einer Flusstafel dann eben entsprechend so zeichnen,
dann kann man sich da also noch sagen, okay,
also jetzt soll der Zieler nicht nur vorwärts,
sondern auch noch rückwärts zählen.
Gut, also das sind jetzt hier nur Beispiele,
wie man sowas dann letztendlich dann irgendwie formal beschreibt,
lässt sich dann natürlich beliebig kompliziert machen.
Ich kann jetzt auch noch sagen, gut,
er soll jetzt nicht nur vorwärts und rückwärts zählen und anhalten.
Da soll das auch noch ein Reset geben. Wenn das jetzt gedrückt wird,
dann geht er von jedem Zustand, wo er ist,
dann eben wieder hier in den Zähler stand. Null zurück. Und je nachdem,
wie viele Zählerzustände es hier gibt, habe ich dann natürlich,
also hier entsprechend Knoten in so einem Graphen und okay,
da sieht man dann also auch schon,
waren solche grafischen Beschreibungen eben nicht mehr so richtig viel Sinn machen bzw. nicht mehr so richtig übersichtlich sind.
Wenn ich sage, ich habe hier zwischen vier und zehn Zuständen,
dann kriege ich das noch irgendwie einigermaßen übersichtlich hin und kann das also auch noch irgendwie visualisieren und nachvollziehen,
wenn das März Zustände sind, macht das also irgendwie da nicht mehr Sinn.
Nicht, dass das auch noch mal so ein bisschen die Motivation eigentlich für so hierarchische Beschreibung,
wie das in Stage-Charts drin ist,
weil damit kann man dann eben wirklich Automaten,
die letztendlich aus mehreren hunderten Zuständen bestehen,
relativ übersichtlich und also auch von den Menschen nachvollziehbar kompakt beschreiben,
weil man sagen kann,
Kapsel das jetzt in unterschiedliche Hierarchie-Ebenen und auf oberster Ebene habe ich meine Hauptzustände und von da aus verteidige ich weiter.
Eine andere Sache oder ein anderes Thema,
was hier jetzt auch nicht mit drauf ist,
wenn ich jetzt also eine Ampelschaltung nehme und das letztendlich realistisch beschreibe.
Kann ich jetzt natürlich sagen, gut, wie würde das eigentlich funktionieren?
Also angenommen, es sollen jetzt also hier diese vier Zustände der Reihe nach irgendwie durchlaufen.
Und von dem Zustand, zu dem Zustand,
beziehungsweise hier bei dem Grünen sollen halt eben gewisse Zeiten vergehen.
Wie würde sowas in den technischen Systemen passieren? Da ist
es jetzt ja so, ich kann in dem Computer keine Zeiten messen.
Absolut gesehen kann ich erst mal keine Zeiten messen.
Nicht, was mache ich als Mensch? Also ich habe irgendwie
einen Stopp, wo ich sage Start, ich sage Stopp.
Mechanisch schwingt da irgendwie was und das, was passiert,
ist, dass die Anzahl der Schwingung in der Unruhe,
der Uhr letztendlich gezählt wird. So und beim technischen System passiert also auch nichts anderes. Das heißt,
wenn im Computer irgendwo Zeiten misst, passiert auch nichts anderes,
als dass man sagen kann, ich kann jetzt nicht sagen,
die Zeit, die Zeit, sondern das, was man macht,
ist, dass man sagt, ich habe irgendwo mal eine Taktfrequenz,
die läuft mit so und so viel Megaherz oder Gigaherz irgendwie vor sich hin.
Mit dieser Taktfrequenz lasse ich einen Zähler laufen und wenn ich sage,
Start, dann wird der Zähler auf Null zurückgesetzt,
läuft dann mit so und so viel Megaherz meinetwegen jetzt vor sich hin,
wenn ich dann das wieder drauf drücke,
stopp, kann ich einen Zählerstand auslesen,
habe quasi meine Taktperiode und kann daraufhin sagen,
die und die Zeit ist vergangen
Das heißt, in einem Rechner Zeiten messen ist einfach immer abhängig von
irgendeinem Basisgrundtakt letztendlich die Taktfrequenz oder die Anzahl der Vorderflanken,
sage ich mal, jetzt irgendwie mitzuzählen. Gut,
wenn ich das jetzt aber nehme,
um jetzt also hier irgendwie so eine Abelsschaltung zu machen und das Ding soll jetzt also irgendwie realistisch sagen,
okay, ich habe hier irgendwie die Rotphase, die soll 30 Sekunden dauern,
nicht dann habe ich hier also irgendwie rot-gelb für fünf Sekunden lang,
dann soll Grünphase irgendwie 40 Sekunden lang sein,
dann soll irgendwie dieser Übergang passieren.
Wie würde man sowas jetzt machen? Da müsste man dann eben,
wenn ich das jetzt wirklich als technisches System mache, eben sagen, okay,
also jetzt in Hardware auf unterster Ebene, was ist der Grundtakt von meinem System?
Das heißt, welche Taktfrequenz liegt dem Ganzen zugrunde?
Und ich mache daraus dann eigentlich einen Automaten, wo zwischenzeitlich immer Zeit gezählt wird. Jetzt kann ich natürlich sagen,
zwischenzeitlich Zeit zählen, einfachste Variante wäre zu sagen,
ich habe hier diesen Zustand und es soll jetzt meinetwegen eine Sekunde lang vergehen und das Ganze wird mit dem Kiloherztag betrieben,
kann ich natürlich sagen, okay,
dann mache ich also aus diesem einen Zustand tausend Zustände,
die hier quasi erstmal ohne Bedingung von einem zum nächsten,
zum nächsten übergehen und irgendwann am Ende kann ich sagen,
ist die und die Zeit vergangen.
Macht den Automaten natürlich
ein bisschen unübersichtlich
Das, was man dort dann eigentlich sinnigerweise macht oder machen würde,
ist, dass man sagt,
ich habe eigentlich zwei Automaten, also sprich gekoppelte Automaten,
nämlich einmal ein Zähler, wo man sagt,
wenn ich hier in diesen Zustand reingehe, wird der Zähler zurückgesetzt.
Anschließend habe ich hier quasi als Bedingung Count kleiner 1000 und
hätte dann hier für den Fall Account. Gleich 1000,
wobei in dem Fall würde ich dann bis 1001 zählen.
Also von daher ist das jetzt auch nicht so ganz schlau,
aber okay. Entsprechend den Übergang in den nächsten Zustand,
wo dann eben der Zähler wieder zurückgesetzt wird.
Die formal gesehen ist das dann aber eben ja nichts anderes,
als dass man zwei Automaten hat,
nämlich einmal den Zähler und einmal irgendwie so einen Hauptautomaten.
Nicht also auch das so ein Beispiel für,
wo man im Prinzip jetzt über so eine Hierarchie im Sinne,
wie das also auch ein Stage hat,
der Fall ist,
dass Ganze dann eigentlich immer ganz gut beschreiben oder zusammenfassen kann
Ne, das ist also dann die Art und Weise,
wie in dem Sinne dann jetzt irgendwo Zeit vergeht,
in der Programmierung würde man es eh nicht machen.
Also da kann man sich dann auch irgendwo Zähler oder Zeiten definieren.
Dahinter verbirgt sich dann eigentlich auch irgendwie sowas wie Interakt interabgetriebenen Mechanismus,
der dann also dafür sorgt,
dass das Programm an der Stelle dann quasi angehalten wird und nach Ablauf einer bestimmten Zeit,
wo dann eben letztendlich mit Taktfrequenzen Zähler irgendwie läuft und wenn
da abgelaufen ist,
läuft es dann eben an der Stelle
entsprechend weiter
Gut, ja, solche Zähler, wie kann man die dann also irgendwie aufbauen?
Also sind jetzt hier nur irgendwie so ein paar unterschiedliche Hadesschaltungen,
nicht also einmal so irgendwie aus solchen JK-Flipflops.
Wenn ich jetzt also letztendlich binär zähle,
wann habe ich einen Übertrag von einer Stelle zur nächsten?
Das ist ja immer nur das, was man sich da eigentlich fragen muss. Und da habe ich dann eben beispielsweise,
wenn ich jetzt also hier 00,
01 und dann jetzt sich jeden Übergang nach 1-0 mache,
dass ich da dann eben sage, okay,
wenn Dieses Bild null ist und alle da drunter liegenden Bits quasi gleich eins sind nicht,
dann habe ich den Übergang,
dass ich an der Stelle eine Eins bekomme und alle niedrigeren Witzen eine Null.
Und je nachdem, welche Art von Flip-Flop ich da irgendwie
drin habe, kann man das dann eben entweder realisieren.
Also hier wird dann also quasi ein Reset gemacht,
wenn eben diese beiden Bits hier eins sind,
soll hier was passieren an dieser Stelle,
wenn diese drei Bits gleich eins sind.
Also im Prinzip wird da dann einfach nur Schaltalgebrage
das Ganze
irgendwo umgesetzt
Nicht mit D-Flipflops, also letztendlich genau das Gleiche.
Also die habe ich dann, also diese Unverknüpfung von Carry Ehen,
also das ist jetzt noch kaskadierbar und dementsprechenden Bett hier und
dem Bett der nächsten Stufe und dem Bett der nächsten Stufe nicht.
Und damit steuere ich dann also,
dass er hier an der Stelle wechselt, aber nur,
wenn er aktuell den Wert null hat, was also letztendlich dann,
also hier durch diese X-Ohr-Verknüpfung gemacht ist,
dass ich eben abfrage, ist der hier gleich null?
Sind alle niedrigeren eins? Dann soll er sich ändern.
Ansonsten Soll er sich entsprechend nicht ändern. Also das sind dann immer die Bedingungen,
die man da dann darüber entsprechend mitmachen kann,
was man dann also quasi in Schaltalgebar dort irgendwie da reinkodieren muss.
So, was man bei Zählern dann auch immer noch findet,
als Beispiel, beziehungsweise was man, wo man also Zählern deutlich einfacher eigentlich noch aufbauen kann.
Hier sieht es jetzt so aus, das sind sogenannte synchrone Zähler.
Das heißt also, alle Flipflops kriegen identisches Taktsignal
Das heißt, wenn der Takt kommt, habe ich eben
auch wirklich eins zu eins diesen Übergang von dem Zählerzustand in den Zählerzustand.
Ohne, dass ich da jetzt also irgendwelche Hazards drin habe. Zähle einfacher aufzubauen,
geht im Prinzip über sogenannte asynchrone Zähler, wo ich dann sage,
ich habe hier ein Taktsignal und dieser erste Zähler macht nichts anderes,
als dass er immer nur zwischen 0 und 1 wechselt,
weil das ist ja letztendlich das,
was beim Zählerzustand in den niederwärtigsten oder beim Zählen im niederwärtigsten Bit
immer passiert
So, und dieser Wechsel zwischen 0 und 1 hat ja verglichen mit
dem Eingangstakt-Signal 0 und 1 die halbe Periodendauer, die halbe Hand.
Falsch, die halbe Frequenz, die doppelte Periodendauer, so rum.
So, und das kann ich jetzt wieder nehmen als Taktsignal der nächsten Stufe. Das heißt,
das, was man damit macht, ist,
dass man sagt, ich habe hier mein Eingangstakt,
habe dann entsprechend So wurde es aussehen,
hier den Tag der ersten Stufe,
den nehme ich jetzt wieder als Takt für die nächste Stufe und so weiter.
Das heißt, von einer Stufe zur nächsten Stufe habe ich dann
immer die Frequenz durch zwei geteilt. Das ist das,
was die Oma angedeutet ist oder eben entsprechend die Periode verdoppelt.
So, und nicht damit kriegt man entsprechenden auch
einen Fehler hin
Der kann weise dazwischen keine Logik mehr ist, also anders
als hier bei sowas, natürlich sehr schnell getaktet werden.
Aber was hier passiert, ist,
dass die einzelnen Witz nicht mehr gleichzeitig umschalten, sondern nacheinander.
Das heißt also, es kommt erst die Taktflanke hier,
ein bisschen später kommt die Taktflanke hier,
wenn diese Taktflanke jetzt quasi wieder eine Stufe später was umschaltet,
sind die immer so ein bisschen gegeneinander verschoben.
Das ist dann eben der Nachteil,
der sich bei solchen Asynchronzählern
letztendlich ergibt
Gut, hier dann also auch noch mal Beispiele,
wo dann also auch noch mal drin ist.
Also man kann das dann also auch, je nachdem,
wie man das zusammenschaltet, vorwärts zählen, rückwärts zählen und so weiter.
Gut, damit werde ich dann für heute Schluss machen.
Die ist abschließende Beispiel, dann nächstes Mal noch ganz kurz erklären.
Dann sind wir eigentlich jetzt mit diesem Kapitel Schaltwerke soweit.
Durch und dann wird das Ganze ein bisschen konkreter in dem Sinne Computer, Rechnersysteme,
weil dann geht es dann im Prinzip in die Rechnerarchitektur,
beziehungsweise dann Befehlssätze.
Gut,
dann ein schönes Wochenende