So. Also, nach dem Durchtauschen der Kabel
haben wir jetzt also auch ein vernünftiges Bild. Ja,
ich hatte ja letzte Woche aufgehört mit der Beschreibung von Schaltwerken,
der Definition, was Schaltwerke sind.
Eben diese Unterscheidung von Asynchronenschaltwerken, wo man jetzt eben sagt,
okay, wir nehmen sauber entworfene asynchronische Haltwerke,
also beispielsweise Flankengesteuerte
Flipflops, als Rückkopplungselemente jetzt in generellen Schaltwerken und eben erhalten dadurch dann eben
ein synchrones Schaltwerk und hatte da ja dann also schon einiges vorgestellt,
beziehungsweise hatte letztendlich aufgehört mit Überlegungen zur Taktung, beziehungsweise dann eben nochmal kurz gezeigt,
wie dann also im Prinzip sowas mit so einem Zwei-Phasen-Takt funktioniert.
Ja, abschließend eigentlich jetzt mit diesem Kapitel Schaltwerke werde ich
heute also jetzt erst mal vorstellen, wie man also Schaltwerke beschreibt, spezifizieren kann.
Das heißt, so ein bisschen mehr formaler,
die man letztendlich dann braucht, um Schaltwerke zu entwerfen.
Anschließend werde ich dann auch noch einiges an Beispielen vorstellen,
zu Schaltwerken, was man sich da dann als einfache Schaltwerke,
so ein Minimalbeispiel, Ampelschaltung beziehungsweise einige Zählerschaltungen vorstellen und dann dieses Kapitel damit dann entsprechend abschließen.
Ja, wenn man jetzt Schaltwerke beschreiben möchte,
da hat man also vergleichsweise viele Möglichkeiten, kann das entweder textuell machen.
Oder eben grafisch in Form von solchen Zustandsdiagrammen. Und als dritte Möglichkeit,
auf die wir den hier eigentlich jetzt aber nicht weiter eingehen werden,
also im Prinzip sowas wie Funktionale Beschreibung,
jetzt im Sinne so eine imperativen Anweisung, wie sie also beispielsweise in Hardware-Beschreibungssprachung genutzt werden.
Als Textuelle oder als Beschreibung kann man eben erstmal sagen,
okay, ich kann, Schaltwerke sind spezifiziert durch die ihre beiden Funktionen,
Zustands, Übergangsfunktionen, Delta, beziehungsweise die Ausgabefunktion Lamda.
Daraus kann ich dann sagen, ich kann das Ganze dann
eben erstmal in Form von solchen Tabellen aufstellen,
was dann Flusstafeln bzw. Ausgangstafeln sind.
Flusstafel beschreibt quasi das Delta Schaltnetz, das heißt,
ich habe in einer Tabelle den aktuellen Zustand und sage dann
eben,
wie jetzt
der Folgezustand aussieht
Unter einer bestimmten Eingangsbedingung und Ausgangstafel wäre dann eben,
dass ich abhängig vom Zustand dann eben den jeweiligen Ausgangsvektor beschreibe,
wobei das Ganze dann eben entweder bei einem Moorautomaten,
nur als Funktion des aktuellen Zustands stattfindet,
bei einem Media-Automaten hätte ich dann eben auch noch
die Abhängigkeit von einem Eingangsvektor und hätte dadurch dann also eine
entsprechend größere Tabelle und das wäre dann eben funktionale Beschreibung
des Landerschaltenletzes
Gut, Trivialbeispiel. Ambel soll jetzt einfach immer nur durchschalten.
Vier Zustände, rot, rot, gelb, grün.
Und nach der grünen Phase kommt da wieder gelb und anschließend wieder rot.
Wenn ich das jetzt beispielsweise als zwei Bit vektokodiere,
also spreche mit zwei Zustandsvariablen,
einfach jetzt irgendwie binär durchnummeriere, wäre dann die Flusstafel,
trivialerweise einfach dieses,
dass ich sage,
also ich habe hier irgendwo
meinen aktuellen Zustand und hier dann eben
ein Folgezustand
Ausgangstafel, entsprechend, wenn das Ganze jetzt eben ein Moorautomat ist,
Zustand und hier dann eben der entsprechende Ausgangsvektor. So,
und dann kann ich jetzt sagen, wenn ich das jetzt nehme,
habe ich hier abhängig von meinem Zustand drei Ausgänge,
beziehungsweise hier abhängig von meinem Zustand zwei Ausgänge und könnte das Ganze dann eben jetzt einfach als Funktionstabelle entsprechend nehmen,
Dann zum Beispiel ein KV-Diagramm eintragen und entsprechend minimieren.
Das ist, wäre jetzt also im Prinzip eine tabellenartige Beschreibung des Automaten,
das, was man häufiger findet,
weil es das auch noch ein bisschen anschaulicher auch erstmal ist, sind Zustandsdiagramme,
hatte ich also am Freitag her so auch schon bei einigen Beispielen kurz gezeigt,
dass es dann eben wirklich so eine grafische Darstellung,
wo ich dann eben wirklich sehen kann, okay,
ich habe für jeden Zustand ein Knoten.
Ich habe dann für jeden Zustandsübergang dann eben eine entsprechende Kante.
Ich die Knoten entsprechenden eben den Zuständen an dem Kanten habe ich
quasi als Eingabebedingung und da der eben ein Zustandswechsel stattfindet,
dann das entsprechende Eingabemuster dort vermerkt und sehe dann eben wirklich direkt, wie das Ganze funktioniert.
Und bei den Ausgängen würde man das dann eben entsprechend so unterteilen,
dass ich sage, beim Murschaltwerk hängt der Ausgangsvektor nur vom aktuellen Zustand ab.
Also schreibe ich den quasi in diesen Knoten, in diesen Bubble mit rein.
Die Ausgabe wird also zusammen mit dem Knoten notiert.
Beim Mili-Schaltwerk hängt der Ausgangsvektor vom Zustand und von dem Eingangsvektor ab.
Also schreibe ich den Ausgangswektor dann quasi an die Kante mit dran.
Sieht man in den folgenden zwei Folien beim Moorautomaten, also hier so ein einfacher Automat. Ich habe vier Zustände,
A, B, C, D,
nicht nur notiere das Ganze eben immer so,
dass ich sage,
hier ist also irgendwie die Bezeichnung des Zustands beim Moorautomat Henker-Ausgangswert nur vom Zustand ab,
wird den zufolge hier in diesen Knoten mit reingeschrieben,
habe hier also jetzt mal einen Ausgangsvektor und hätte dann hier eine Bedingung,
unter der ich jetzt eben den Zustand A verlasse in den Zustand B gehe.
Das heißt also hier beispielsweise, wenn x gleich eins ist,
würde ich in diesen Zustand wechseln,
wenn x gleich null ist,
wird diese Kante wahr und ich würde eben in den Zustand C wechseln.
Nicht so ist das Ganze
dann demzufolge zu lesen
Was man dann häufig auch noch mit in den Markierungen mit drin stehen hat, ist,
dass man dann also quasi so was wie einen Staatszustand markiert,
wird dann oft so gemacht.
Das sind also hier quasi so ein kleines Segment entsprechend noch
mit angezeichnet, wird schwarz, dass man sieht,
dass es eben da als ausgewählter Zustand, als Staatszustand.
Häufig finden sich auch solche Sachen wie also irgendwelche doppelten oder dickeren Kreise,
also dass man das dann also auch nochmal ein bisschen markiert.
Bei Mili-Automaten hier also ein Eine ähnliche Konfiguration,
nur dass ich hier jetzt eben sage, okay,
der Ausgangswert hängt jetzt eben nicht nur vom Zustand,
sondern eben auch von irgendeiner Eingangsbedingung ab.
Demzufolge werden dann bei Mili-Automaten die Ausgangswerte dann eben quasi auch hier
in dieser Kante mit notiert, ist eben so zu lesen,
dass ich sagen kann, ich bin in dem Zustand A.
Wenn x gleich 1 ist, würde ich im nächsten Tag
oder im nächsten Zustand in den Zustand B gehen und Ich erhalte als Ausgangsvektor 100.
Und wenn x gleich null ist, würde ich ins See gehen.
Ich erhalte als Ausgangsvektor 1, 1-1. Das wäre also das,
wie man als Zustandsdiagramm Moore beziehungsweise Mili-Automaten notiert.
Was man häufig noch findet, sind dann sogenannte Stageharts.
Das sind Erweiterungen von Zustandsdiagrammen, wurden von David Harrell Mitte der 80er Jahre eingeführt.
Und Stake Charts erlauben jetzt also, dass ich nicht nur normal Zustandsdiagrammen habe,
sondern also da gibt es eben noch zwei zusätzliche Konzepte.
Zum einen kann ich in Stage Charts sowas wie Hierarchien beschreiben.
Das heißt also, ein Zustand kann einem eigenen Unterautomaten entsprechen.
Dadurch kann ich dann eben sagen,
ich kann also relativ übersichtlich auf einer Ebene,
also irgendwo oben einen Automaten beschreiben und den dann also immer weiter verfeinern und sagen,
okay,
in diesem Zustand,
dahinter verbirgt sich dann eigentlich wieder ein eigener Automaten mit entsprechenden
unter Zuständen
Wenn ich zusätzlich gibt es dann eben noch die Möglichkeit,
daran solche sowas wie so eine Art History-Mechanismus einzubetten.
Dahinter steht dann letztendlich die Frage, was passiert,
wenn ich jetzt meinen Unterautomaten in der Hierarchie verlasse,
jetzt quasi in einen ganz anderen Zustand in der übergeordneten Ebene gehe und dann wieder zurückspringen.
Wo setze ich da auf, dass man da dann eben
auch Mechanismen hat, die dann quasi sowas wie Zwischenzustände speichern können.
Als zweites gibt es dann bei Stageharts Erweiterungen, wo es also um Nebenläufigkeiten geht,
dass man dort dann eben quasi parallel arbeitende endliche Automaten, auch entsprechend mitbeschreiben kann.
Ja, sowas wie Stageharts sind also vergleichsweise beliebte Spezifikation für sehr komplexe Automaten,
gerade im Bereich des Entwurfs von allen gebettelten Systemen findet man das also sehr oft.
Dort werden die also ganz gerne verwahrt und werden auch teilweise,
also nach Hilfe auch gleich noch ein kurzes Beispiel, dann auch durch irgendwelche Bibliotheken softwareseitig unterstützt,
dass man da dann also auch solche Automaten Sehr einfach spezifizieren und beschreiben kann,
wenn ich jetzt also im Prinzip so ein Verhalten wie so ein Automat, also jetzt eine Software benutzen möchte. Nicht ursprünglich,
wie gesagt, in den 80er Jahren entwickelt,
das ist dann das berühmte Beispiel aus dem Paper von Harrell,
nicht wo es darum ging, dann so eine LCD-Digitaluhr,
was inzwischen ja nun auch schon wieder als Retro in seinen Markt zu beschreiben von der Funktionsweise,
wo ich dann eben hier als Abläufe jetzt meiner Automaten habe,
nicht und hier quasi mit diesen Kapselungen ineinander ist,
dann letztendlich angedeutet, diese Hierarchien,
die da mit drin sind und was da alles,
also letztendlich passieren muss, nicht,
aber das ist einfach nur mal so als Beispiel zu nehmen,
dass man wirklich so ein Verhalten,
ich drücke die Taste und dann soll das und das passieren
oder dann bin ich in dem Betriebsmodus eben sehr schön
mit diesen Hilfsmitteln endlichen Automaten entsprechend gut spezifizieren kann
Deswegen, also um das nochmal so ein bisschen zu veranschaulichen,
das hatte ich jetzt also im Prinzip letzte Woche nämlich noch neu mit reingenommen,
habe ich hier nochmal so ein paar Folien,
wo es also nochmal so generell um endliche Automaten ging.
Nicht, weil das war jetzt also eigentlich als Reaktion auf meine Frage,
sind endliche Automaten irgendwo bei jetzt eh schon mal vorgekommen. Und deswegen,
also hier nur kurzer Einschub,
also endliche Automaten sind eben wirklich so ein Vergleichsweise häufig benutztes Konzept in der Informatik,
also sowohl in der Programmierung als auch im Hardwareentwurf als auch in der Modellierung von Systemen,
weil man dort also wirklich sehr schön beschreiben kann,
wie jetzt also irgendwie interne Systemzustände sich irgendwo abwechseln,
wie ein System von einem Zustand in anderen Zustand übergeht,
wie dieses System auf irgendwie externe Ereignisse reagieren kann.
Oder wie ich jetzt also irgendwelche Aktionen,
die jetzt der Reihe nach passieren, letztendlich beschreiben kann.
Das geht dann eben weiter auch jetzt in bestimmte Anwendungsszenarien,
also zum Beispiel fatalte Systeme,
irgendwelche kleinen Serverarchitekturen,
da findet man das oft
Es gibt eine Erweiterung für Echtzeitsysteme, wo ich dann eben
auch noch zusätzlich so was wie Timeouts mit beschreiben kann,
eingebettetes System, hat ja schon erwähnt, erwähnt,
da gibt es also relativ viel an Beispielen.
Hier nur ganz kurz skizziert, nicht also häufig findet man
das natürlich und da würde es ihnen dann auch noch begegnen,
also irgendwo in der Theorie. Also wenn ich jetzt sage,
ich möchte also hier irgendwie sowas wie ein Pasa schreiben,
also ich möchte als Wort A, B,
A erkennen, nicht dann wäre das also folgender Automat,
ich starte hier als Startzustand in
S3 ist dann mein Terminalzustand, wo ich dann sage,
ich habe das Wort erkannt und das passiert eben genau hier über diese Übergänge.
Und wenn ich hier in S4 als Fehlerzustand lande,
dann habe ich eben irgendwas Falsches gepasst.
Also das wäre eine Anwendung, wo man solche Automaten anwenden kann.
Anderes Beispiel Game Design, Verhalten eines Spots. Also sprich,
der fängt irgendwo an, wandert in meiner künstlichen Welt rum.
Wenn der Spieler oder die Spielerfigur in der Nähe ist,
dann soll der Bot
den angreifen
Für den nächsten soll er wieder weiter rum wandern. Nicht dann,
wenn die sich hier also irgendwie gegenseitig behaken,
kann man sagen, na gut, wenn der Player zurückschlägt,
versuche ich zu fliehen.
Wenn der Player nicht zurückschlägt, greife ich wieder an. Und gut,
wenn es zwischenzeitlich dann also irgendwie die Gesundheit zu sehr leihen sollte,
versuche ich dann eben irgendwie entsprechend einen Power abzufinden oder sowas.
Nicht, also das auch nur als so ein einfaches Modell,
wie man eben mit solchen Automatenmodellen jetzt eben solchen Anführungszeichen intelligenten Verhaltensweisen nachbilden möchte.
Also intelligent ist das Ding natürlich nicht, aber nicht,
also nur um zu zeigen,
wie sowas ist
Anderes Beispiel, mich verteiltes System, kleinen Serverarchitektur,
das ist im Prinzip also außer Dokumentation, so einer Softwarebibliothek,
die im Prinzip hier für Ross mit benutzt wird.
Ross steht für Robert Operating System,
das ist dann im Prinzip dann auch so zum Betreiben von Robotern so eine verteilte Architektur,
wo ich dann eben sagen kann, okay, ich habe hier einen Server,
der gibt eben an einen Client irgendeinen Auftrag und der Auftrag wird eben entweder erfüllt,
abgebrochen, zurückgezogen zurückgewiesen oder was auch immer.
Und da gibt es dann eben entsprechende Automaten,
sowohl für den Server als auch für den Client,
wo ich eben unter bestimmten Bedingungen diese oder jene Aktion habe. Also das nur als zum Beispiel, wie man eben mit solchen Automatenbeschreibungen doch relativ häufig umgeht. Dies hier war nochmal dieses Beispiel Stagehart-Bibliothek,
das ist also auch im Prinzip eine Bibliothek,
die häufig in der Programmierung benutzt wird, boost,
wo es dann eben auch eine Stagehart-Bibliothek gibt und hier als ein Beispiel dieser Bibliothek dann also was wie so eine Digitalkamera,
wo ich sage, okay,
wenn ich jetzt nicht gerade was aufnehme,
dann bin ich also entweder im Eidelmodus oder der Benutzer drückt eine Taste,
dann gehe ich eben in Konfigurationsmodus,
nicht hier hinterfürbirgt sich dann wieder ein eigener Automat,
wenn ich anfange, den Auslöser zu drücken,
dann gehe ich eben in diesen Modus,
dass ein Bild aufgenommen wird und auch das wird dann also quasi hierarchisch weiter unterteilt,
wo ich dann sage, okay, also dieses Bild aufnehmen,
fokussieren,
wenn fokussiert worden ist,
wird es aufgenommen und so weiter und so fort
Hier auch nur ein Beispiel, also jetzt einfach per Suchmaschine schnell rausgesucht.
Also auch zur Unterstützung von Automaten, um sowas dann zu machen,
gibt es dann eben auch sowas wie irgendwelche Editoren oder Code-Generatoren,
wo man dann im Prinzip sowas,
also solche grafischen Beschreibungen dann eben auch wirklich noch irgendwie entsprechend einfach grafisch eingeben kann.
Gut, also da lassen sich noch beliebig viele weitere Beispiele finden. Wie gesagt,
bei uns hier in Rechnerstrukturen, endliche Automaten,
also wirklich ganz unten, eher als Beschreibungs- oder Militärungshilfsmittel auf der Hardware-Ebene,
wo ich jetzt eben sage, ich habe jetzt eben irgendwelche einfache Hardware,
die jetzt also irgendwie bestimmte Aktionen unterstützen möchte.
Wo sich das noch findet,
wobei ich jetzt hier allerdings auch kein weitergehendes Beispiel habe,
weil das dann also, denke ich mal,
aus Zeitgründen auch nichts weiterbringt wird und also bei Hardware-Beschreibungssprachen,
wo ich dann eben sage, dieses Verhalten eines Schaltwerks,
was ich ja also entweder als Zustandsdiagramm oder eben über Fluss- und Ausgangstafel beschrieben habe,
kann ich eben auch imperativ festlegen und das kann man eben entweder mit Mitteln der normalen Programmiersprache machen.
Das wäre dann etwas, was also beispielsweise hier in solchen Bibliotheken mit unterstützt wird.
Ich kann das dann aber eben auch mit Hardwarebeschreibungssprachen machen,
typischerweise wären das VHDL, Very Lock oder System C,
also sagen wir mal so die drei am meisten gebräuchlichen Hardware-Beschreibungssprachen,
nicht wo man dann im Prinzip auch solche Automaten sehr einfach beschreiben kann.
In solchen Sprachen hat man dann eben die Möglichkeit,
auch zu sagen, gut, ich beschreibe einmal diese Zustandsübergänge,
unter welchem Eingängs, Eingangsbedingungen mache ich welche Zustände,
als Folgezustand, wie sieht das da mit den Ausgängen aus,
Ich kann dann eben das Zeitverhalten der Schaltung noch genauer spezifizieren und ich habe da dann eben auch Möglichkeiten,
weil das ist natürlich auch in der Hardware eigentlich immer inhärent vorhanden,
dass ich dann also Parallelität beschreiben kann.
Und da wird das dann eben entsprechend auch weiter genutzt. Wie gesagt,
hier im Vorgene jetzt nicht weiter beschrieben,
hier kommen noch zwei Beispiele,
wie jetzt erstmal nur sowas wie so ein generell so ein bisschen Hardware-Beschreibungssprache aussieht,
also in diesem Fall einfach so ein einfaches B-Flip-Flop,
hier einmal in Very Lock
Auf der nächsten Folie in VHDL,
nicht wo man dann eben auch letztendlich nur sagt,
okay, die Hardware hat hier irgendwelche Eingangssignale, Clock,
Reset, Dateneingang, Datenausgang.
Und was dort passieren soll, ist,
dass wenn ich eine Taktforderflanke habe,
war der Clock oder wenn das Reset aktiv ist,
passiert hier am Datenausgang was.
Und zwar, wenn das Resect aktiv ist, wird er
wert auf null zurückgesetzt. Ansonsten quasi bei diesem Ls würde
hier als Bedingung gegriffen haben, dass ich eine Tagforderflanke habe.
Und dann wird eben der Dateneingang quasi zugewiesen und bleibt dann eben gespeichert.
Nicht, das ist also die Art und Weise,
wie das in der einen Hardware-Beschreibungssprache aussieht,
in VHDL würde das dann so aussehen, auch ähnliches Konzept.
Also ich habe immer so eine Unterteilung zwischen so einer Blackbox-Beschreibung,
was sind Ein- und Ausgänge der Schaltung und hier irgendwo das Verhalten.
Nicht hier ist es dann so ein Prozess,
wo ich dann eben sage,
Freeset Life 1,
Datenausgang gleich Null
Elsif Rising Edge from Clock, das ist in dem Sinne vordefinierte Funktion,
die eben sah, abfragt, habe ich eine Vorderflanke,
lieferten Bulschenwert zurück. Und wenn ich eine Vorderflanke habe,
wird der Dateneingang hier zugewiesen und bleibt dann eben gespeichert.
Und wenn ich keine Vorderflanke habe, das heißt,
der Tag dann eben konstant eins ist oder null oder wenn
ich eine Rückflanke hätte, findet hier nichts statt.
Und das, was irgendwann hier mal dem D-Out zugewiesen wurde, bleibt dann eben gespeichert.
Mich das also nur grob zu der Art und Weise,
wie man dann also im Prinzip auch so ein Verhalten von Hardware, eben auch textuell beschreiben kann.
Gut, hier möchte ich jetzt eigentlich noch mit der Frage weitermachen, wie entwirft man Schaltwerke? Wie kommt man jetzt eigentlich dazu,
wenn ich sage, Ampelschal, Steuerung oder den Automaten,
der mit dem Bord steuert oder was auch immer,
wie mache ich daraus jetzt wirklich,
also dann meine Hardware oder mein System,
das würde dann grob gesehen eigentlich so aussehen,
dass ich sage, als erstes muss ich das Ganze irgendwie spezifizieren,
entweder textuell durch Flosstafeln und Ausgangstafel oder eben entsprechend grafisch durch ein Zustandsdiagramm.
Nicht dann würde man eben, wenn ich,
meistens fängt mein Zustandsdiagramm an, dann im Prinzip so eine Übergangstabelle aufstellen.
Irgendwo nochmal gucken, kann ich die Zustände nochmal entsprechend reduzieren?
Gibt es dort also irgendwelche Redundanzen mit drin?
Anschließend würde man sich eben überlegen, wie wären die Zustände
kodiert?
Wie näher
Und dann erhalte ich dann eben im Prinzip die Übergangstabelle und kann dann eben ganz normal,
wie beim Schaltennetzentwurf, dann eben die Schaltennetze minimieren.
Und das Ganze dann realisieren. Anschließend würde man das dann eben nochmal entsprechend überprüfen.
So, hört sich jetzt natürlich immer ganz einfach an.
Ich fange also irgendwo oben mit so einem Zustandsdiagramm an und gehe da also,
es dreht vorward runter und habe dann also irgendwann mal fertiges Ergebnis.
Meistens sieht das so aus,
wenn es jetzt nicht gerade irgendwas ganz Triviales ist,
wie also hier die meisten Wahlspiele,
dass man dann eben doch schon ein paar mehr Iterationen benötigt,
weil gerade weil man dann eben auch sehen kann,
je nach Art der Realisierung sind die realisierten Systeme entweder komplizierter oder einfacher und dass man dann eben auch mal so ein bisschen guckt,
also welches ist jetzt vielleicht besser geeignet.
Festmachen möchte ich das Ganze hier jetzt nochmal annehmen,
Beispiel Zustandskodierung, also sprich der Fragestellung,
wenn ich jetzt also so ein die auch immer geartet ist, Zustandsübergangsdiagramm habe.
Ich habe meine Zustände benannt. Ich habe jetzt also festgestellt,
unter welchen Bedingungen habe ich irgendwie Zustandsübergänge?
Wie kodiere ich das? Da kann ich jetzt eben sagen,
gut, allereinfachste Möglichkeit ist erstmal, das Afa binär durchzuzählen.
Dieser Zustand kriegt den Wert null, der nächste eins,
der nächste zwei und so weiter und so fort.
Eine Möglichkeit. Andere Möglichkeit, sind sowas wie,
gerade wenn ich also irgendwie folgen oder Sequenzen drin habe,
einschrittige Codes zu wählen, ich kann sowas wie One-Hot-Kodierungen nehmen.
Ich kann aber auch jene harte Anwendung mir da also irgendwie
was anderes ausdenken. Nicht und jeder Art der Kodierung,
dazu folgen jetzt live drei Beispiele, sieht man dann eben,
dass dann auch die daraus resultierende Hardware für die Schaltnetze,
also sprich Delta und Lamdaschalennetz,
entweder komplizierter oder eben sehr einfach
sein kann
In der Regel sieht das dann auch so aus,
dass wenn man jetzt da so ein bisschen komplexere Automaten hat und jetzt eben nicht irgendwie sowas mit nur vier Zuständen,
sondern also irgendwas mit 50, 60 Zuständen,
dass man das dann also auch über entsprechende Entwurfswerkzeuge mehr oder minder automatisch durchspielen lässt,
um dann eben zu gucken,
ist diese oder ist irgendeine andere Kodierung dann eben entsprechend besser geeignet,
um dann eben auch einfach mal so ein bisschen Alternativen raussuchen zu lassen bzw. das System kann dann eben auch hinsichtlich der Realisierung dann,
also so eine Schaltnetzminimierung durchführen.
In der Regel, wie gesagt, sieht das so aus, dass man eigentlich mit Funktionstabellen arbeitet. Nicht,
dann habe ich Eingangsbelegungen, kodiere mir das,
bringe das also irgendwie in so ein KV-Diagramm,
fange anders zu minimieren, habe dort dann eben alle Möglichkeiten,
das, was wir hier also auch immer in den Übungsaufgaben hatten,
nicht, wo man dann eben sagt, okay,
also unter bestimmten die ich jetzt nicht benutze,
trage ich dann da eben meine Don't Cass ein,
kann das entsprechend auch noch mit berücksichtigen und erreiche damit dann also vielleicht noch ein etwas einfacheres System oder aber dann entsprechende Vorurteile.
Was einem dann eben auch häufig passiert,
wenn man so einen Automaten entwirft und gerade wenn man jetzt ein bisschen komplexeren Automaten hat,
wo man das jetzt nicht mehr ganz so einfach überblicken kann,
sind entweder Widersprüche in der Automatenbeschreibung, dass ich eben sagen kann,
bei bestimmten Eingangsbelegungen habe ich Also auf einmal irgendwie zwei Kanten aktiv.
Das kann man zwar dann formal in der Theorie so handhaben und sagen,
okay, das ist dann ein nicht deterministischer, endlicher Automat.
Wenn ich natürlich jetzt also sage, das soll irgendein Hardware-System sein,
was mir also ein bestimmtes Verhalten liefert, dann möchte ich eigentlich in der Regel,
also ein Determinismus haben, beziehungsweise andersrum ist es so,
also sowas wie ein richtiger Nicht-Determinismus ist also relativ schwer hinzukriegen.
Das ist also einer der Gründe,
weswegen es also zum Beispiel schwierig ist,
also sowas wie wirkliche Zufallszahlen zu generieren
Jedenfalls. Also da gibt es etwas, was häufig passiert,
dass man da im Prinzip irgendwelche Widersprüchlichkeiten mit einbaut und
was man dann eben auch noch mit abprüfen muss,
sind Vorbedingungen hinsichtlich der Vollständigkeit des Systems.
Sprich, ich habe einfach vergessen,
bestimmte Eingangsvariablen oder bestimmte Verhaltensweisen in meinem Automaten zu beschreiben und
hinterher tritt dann also zufällig jetzt diese nicht beschriebene Sache mit auf.
Ja, was passiert dann eigentlich? Und das kann man
dann eben auch formal überprüfen. Beispiel dazu folgt dann auch
gleich noch
Vollständigkeit. Wie sieht das aus? Ich habe einen Automaten,
ich habe eine Anzahl von Zuständen in meinem Zustandsdiagramm und ich habe also jetzt Kanten,
die zwei Zustände, I und J miteinander verbinden,
quasi als Zustandsübergang, abhängig von einem Eingabe Vector X.
So, um die Vollständigkeit zu überprüfen, muss ich dann quasi jetzt folgende Fragestellung beantworten,
kommen eben auch wirklich alle spezifizierten Eingangsbelegungen in Kanten vor.
Das heißt, Für alle Zustände I muss ich überprüfen,
dass alle möglichen Kanten, die von einem Zustand I auf irgendeinen anderen Zustand J gehen,
mit unter einem bestimmten Eingangsvektor X mit einem,
das all diese Kanten zusammengenommen, quasi jetzt verodert.
Eins ergeben, das heißt also immer wahr werden als Bursche Ausdruck.
Widerspruchsfreiheit Im Prinzip ähnlich. Und zwar muss ich dort gewährleisten,
dass für jeden Zustand und für jedes Paar von Kanten gilt,
dass wenn ich eben von diesem Zustand für jedes Paar,
wenn ich die dann entsprechend unverknüpfe, der Durchschnitt leer ist,
also sprich in der Bulschen Alge war dann eben zusammengeführt,
dass die Oder-Verknüpfung überall alle möglichen Paare oder Paarkombinationen ergibt.
Als Beispiel, da sieht man das dann relativ einfach,
ich habe hier aus einem Automaten hier einen Ausschnitt,
betrachte jetzt hier also erstmal nicht alle Zustände,
sondern erstmal nur den Zustand A. Vollständigkeit wäre jetzt eben zu überprüfen,
für alle Kanten, die von A ausgehen,
die oder Verknüpfung all dieser Kanten ist die gleiche Eins.
Also X1 oder X1 nicht und X0 oder X1 nicht und
Wenn man das entsprechende Bullschen Argebau ausrechnet, gilt das.
Das heißt, dies hier wäre vollständig. Bei der Widerspruchsfreiheit
muss ich jetzt eben jeweils alle ausgehenden Kanten ein paarweise miteinander vergleichen.
Also fange ich an. X-1 und X-1 nicht X-0 oder X-1
nicht und X-0. Also sprich dieser Ausdruck ist gleich null.
X-1 und Diese Kante, also X1 und X1 nicht.
Auch das ist null. Aber wenn ich jetzt die beiden miteinander vergleiche,
X1 nicht und X0 und X1 nicht, das ist ungleich null.
Das heißt, da habe ich in diesem Fall also einen Widerspruch,
beziehungsweise ganz einfach formuliert, wenn ich den Zustand A bin.
Und X1 gleich null ist, welche von den Kanten gilt dann.
Nicht, weil dann wird sowohl diese wahr,
oder andersrum für X1 gleich null und X0 gleich 1,
wird sowohl diese Kante wahr, als auch diese.
Und dann hätte ich damit also quasi einen Widerspruch in
einem System
drin gehabt
Das wäre also dann die Art und Weise,
wie man das jetzt also hier für so ein Beispiel für
einen Zustand und diese drei Kanten dann überprüfen kann.
Gut, jetzt noch einige kleine Beispiele zu Schaltwerken. Ich hatte schon gesagt,
Verkehrsampel mit dem Beispiel unterschiedlicher Zustandskodierung, um eben zu zeigen,
wie sich jetzt eigentlich die Zustandskodierung von Automaten auch wirklich jetzt auf die Komplexität der dort enthaltenen Schaltnetze auswerken,
dann würde ich noch ein bisschen Zielschaltung quasi als Vorstellen,
also quasi als Idee von Automaten und dann eben noch so ein bisschen komplexeres Beispiel.
Das ist aber eigentlich nur, um so ein bisschen zu motivieren,
was dann auch möglich ist. Gut, wie gesagt,
ganz einfaches Beispiel, Ampel, drei Ausgänge, rot,
gelb und grün, vier Zustände, rot, rot,
gelb, grün und gelb, die quasi immer zyklisch hier durchlaufen werden.
Vom Schaltwerksentwurf würde ich dann eben sagen, okay,
als erstes zeichne ich ein entsprechendes Zustandsdiagramm auf, wähle dann eben die Zustandskodierung.
Erstelle daraus dann eben die Tafeln für die Schaltnetze,
die man dann eben entsprechend minimiert und kann das Ganze
dann eben anhand der minimierten Funktion dann eben eingeben,
beziehungsweise dann eben direkt in Hades simulieren.
Erste Variante, vier Zustände, werden jetzt einfach binär durchgezählt.
Demzuvor habe ich dann eben so ein zwei Bit-Vector und die
Fluss- und Ausgangstafeln sehen dann eben So aus,
dass ich hier jetzt eben vom Zustand 0-0 für rot in den Folgezustand 0-1 für rot-gelb übergehe,
von hier aus in den Zustand 1-0 für Grün und so weiter.
Und hätte dann eben hier in diesem Fall handelt es sich also um ein Moorautomaten,
hätte dann eben hier abhängig von dem aktuellen Zustand dann eben einen Ausgangsvektor.
Ich als Zustandsdiagramm, wie gesagt, ist das Ganze
vergleichsweise trivial
Da habe ich hier einfach Brot. Übergang ohne irgendeine Bedingung nach Rot gelb.
Übergang. Auch ohne eine Bedingung. Nach Grün. Gelb. Und geht wieder auf Brot zurück. Gut. Hios,
kann ich jetzt für dass Delta-Schaltnetz,
also sprich die beiden Folgezustände und für das Lamda-Schaltnetz,
also sprich die Ausgänge, hier quasi jetzt meine Schaltfunktion mir überlegen,
kam er jetzt mit KV-Diagramm machen,
beziehungsweise bei diesem relativ einfachen Beispiel,
kann man das natürlich dann also auch versuchen,
direkt hier raus abzulesen und hält dann eben quasi jetzt hier für Z1 plus für den Folgezustand,
dass es eben Einmal hier in der Eins, also sprich Z1. Nicht.
Und Z0, und das ist hier in der Eins,
also sprich Z1, Z0 nicht,
beziehungsweise Z1 exklusiv oder Z0. Z0 nicht, ist nichts anderes.
Oder Z0 plus ist nichts anderes als Z0 negiert.
Und hier für die Ausgänge erhalte ich, rot ist Z1 nicht.
Gelb ist Z0 und grün ist eben hier an dieser
einen einzigen Stelle gesetzt, also Z1, Z0 nicht.
Das ist also hier vergleichsweise einfach direkt rauszulesen,
kam man dann demzufolge anschließend in Hades eingeben und könnte das dann eben entsprechend simulieren.
Also hier ein letztes Mal mal hartes Vorgeführt. Ich wäre jetzt
also hier entsprechend Die Schadung startet in dem Zustand rot.
Tag kommt, ich gehe jetzt nach rot-gelb. Nächster Tag kommt grün,
gelb, wieder rot und so weiter und so fort.
Das als erste Variante, nur um zu sagen, dass es auch anders geht,
vielleicht einfacher, vielleicht komplizierter, wieder die vier Zustände.
Jetzt werden die aber nicht Binär durchnummeriert mit 0-1,
2-3, sondern jetzt sage ich,
ich kodiere dort ein, drei Bit Vector,
wobei die Zustandsbittern einfach entsprechend den Lampen zu wählen sind.
Deswegen habe ich jetzt hier auch die Ausgangsfunktion weggelassen,
weil die ist in dem Fall nämlich minimal,
beziehungsweise der Ausgang ist dann also nichts anderes, als das jeweilige Zustandsbild.
Das heißt, ich sage jetzt hier, gut,
hier ist noch explizit sowas wie ein Reset-Zustand mit drin,
nicht aber ansonsten würde ich eben hier sagen, okay,
der Zustand Rot wird eben kodiert durch Z-2,
gleich Null, Z-1, gleich Null.
Und Z-0. Gleich eins. Nicht, also sprich die grüne und
die gelbe Lampe sind ausgeschaltet. Die rote Lampe ist an,
rot, gelb, hätte ich dann eben logischerweise so kodiert,
grüne Lampe aus, gelbe Lampe an, rote Lampe an.
Nicht grün ist dann eben dieser Fall und gelb ist dieser Fall.
So entsprechend diesem Ablauf würde ich jetzt hier Zustand,
Folgezustand, sagen, okay, Ähm... Wie gesagt,
die Ausgangsfunktion ist minimal. Und die Folgezustände würde man dann eben entsprechend hier rauslesen, minimieren, kodieren und eingeben. Daraus erhält man dann sowas hier als zweite Variante,
in diesem Fall jetzt also mit drei, die vorderflankengesteuerten D-Flip-Flops,
die dann quasi den Zustand kodieren und dann eben hier den entsprechenden Gattern,
entsprechend den logischen Funktionen, Nicht,
wo man dann also im Vergleich zu der anderen Version sagt,
gut, ich brauche jetzt hier ein Flip-Flop mehr,
habe dafür aber hier ein bisschen weniger aufwand und die Ausgänge sind halt eben minimal einfach,
weil die hängen nämlich eben wirklich nur direkt an dem Ausgang,
also wie man dann hier sieht, hier also für Grün hierfür gelb und hierfür rot hängen dann eben einfach direkt an dem Ausgang des jeweiligen Registers drin.
Als dritte Variante, Eine sogenannte One-Hot-Kodierung. One-Hot heißt,
ich habe vier Zustände und in meinem Zustandsvektor ist immer nur ein einzelnes Bit gesetzt.
Das heißt, ich habe hier meinen Zustand,
hätte dann eben hier den Vorgezustand und von einem Zustand zum nächsten Zustand,
wandert dann quasi diese Eins immer entsprechend ein weiter.
Das heißt, ich hätte jetzt Vierbit, bräuchte dem zufolge vier Flip-Flops.
Da wird aber jetzt hier die Übergangsfunktion minimal, weil nichts anderes passiert,
als dass dieser Ausgang von dem Zustand hier in den Ahlengang.
Oder von diesem Register quasi dann in den Eingang des nächsten Registers geht.
Das heißt, da habe ich einfach nur eine direkte Verbindung, wo das Ganze ganz zyklisch miteinander verbunden ist. Und auch die Ausgangsfunktionen sind hier vergleichsweise einfach,
wo ich dann eben sagen kann, okay,
grün wird eben beschrieben durch den Fall Z2,
gleich 1, gelb wird beschrieben,
Durch Z3 gleich 1 oder Z1 gleich 1 und rot ist Z1 oder Z0. Welchen,
das wäre dann die resultierende Hardware,
nicht wo man sagen kann, okay,
hier brauche ich zwar jetzt also auch nochmal ein Flip-Front mehr,
aber wie gesagt, dieses Durchschieben der Eins von einem Zustand zum nächsten ist,
also hier quasi dadurch,
dass hier einfach wirklich immer nur der Ausgang von dem einen in den Eingang des Nächsten und am Ende geht das hier wieder in den Eingang rein.
Einmal so komplett durch und für die Ausgänge habe ich dann eben hier
nichts anderes als entweder die direkten Verbindungen oder eben hier so diese beiden oder Gatta.
Nicht, also das nur als ein Beispiel,
um zu zeigen, also selbst bei so einem wirklich trivialen Beispiel,
wie sich also die Zustandskodierung jetzt eben auf den Aufwand der Delta beziehungsweise lahmder Schaltnetze auswirken kann.
Nicht gut, generell kann man sagen,
wenn ich das Ganze binär durchkodiere, also sprechen Dualkod nehme,
erhalte ich letztendlich die minimale Anzahl oder entsprechende Anzahl der Zustände,
halte ich dann eben minimal wenig Register, die ich benötige.
Andererseits führen eben solche anderen Codierungen, beispielsweise dazu,
dass man dann eben sehr einfache Schaltennetze erhält und dann eben zum Beispiel sagen kann,
ich kann das Ganze möglichst schnell machen oder möglichst einfach realisieren.
Und letztendlich, generell kann man eben sagen,
abhängig von der Codierung, ändern sich eben die Kosten bzw. ändert sich die Performance des Schaltwerks nicht.
Und je nachdem, ob ich das jetzt möglichst schnell betreiben
möchte oder ob das mit möglichst wenig Gattern auskommen soll,
ist entweder die eine oder die andere Realisierung besser geeignet.
Also letztendlich steckt dahinter eigentlich das gleiche Problem, was wir
also auch bei Schaltnetzen, ja also schon gesehen haben.
Nicht, dass ich sagen kann,
wenn ich jetzt zum Beispiel sowas wie ein Adiera betrachte,
als ein etwas komplexeres Schalennetz, nicht,
dass ich sagen kann,
okay,
ich kann das
möglichst klein machen
Bill Carry, Adira, hat dann aber eben den Nachteil,
dass es vergleichsweise langsam ist.
Ich kann das mit dem Carry Look erhebt machen.
Die Schaltung rechnet dann sehr viel schneller,
ist aber vom Hardwareaufwand eben deutlich größer.
Und so ein Trade-Off findet sich dann eben auch genauso letztendlich in den Schaltwerken wieder,
dass ich da ja dann eben auch sagen kann,
je nach Art der Codierung habe ich eben für Delta und Lahmender
Schaltnetze eben entweder sehr einfache oder entsprechend kompliziertere Sachen,
habe dann aber dann vielleicht wieder Vorurteile hinsichtlich der Geschwindigkeit
Gut, das geht jetzt einfach noch mal soweit praktisch zusammengefasst.
Hier jetzt nur noch mal kurz vorgestellt für etwas,
wo man sagen kann, endliche Automate sehe ich ja eigentlich
nicht so, aber im Prinzip sind Zähler.
Wenn wir jetzt sagen, also ich habe also irgendeine Schaltung,
die einfach nur rauf oder runterzählen soll.
Natürlich auch endliche Automaten
Natürlich vergleichsweise einfacher, weil ich da jetzt also keine Riesenverzweigung habe,
sondern ähnlich wie das hier der Fall ist, immer sage,
nicht von Zählerzustand 1, gehe ich nach Zählerzustand 2,
gehe ich nach Zählerzustand 3,
mich und das Ganze dann also ohne entsprechend viel Unterscheidung,
nicht aber eben auch Zielschaltung,
lassen sich letztendlich formal mit den Mitteln des Schaltwerksentwurfs handhaben.
Das heißt, da hätte ich dann eben auch entsprechende Zustandsdiagrammonflusstafeln.
Da werde ich jetzt also hier und gleich nochmal so ein paar einfache Zähler vorstellen,
beziehungsweise dann eben auch zeigen, wie sich da jetzt also unterschiedliche Eingangsbedingungen oder unterschiedliche Kontrollleitungen dann auswirken,
wo ich dann eben sagen kann, okay, soll der Zähler anhaltbar sein, soll er rücksetzbar sein, möchte ich vorwärts und rückwärts zielen. Wie sieht das aus? Gut,
aller einfachstes Beispiel, quasi analog zu dem hier,
zwei Bezähler, Zustandsdiagramm, wie man hier sieht,
nicht, also das einfach nur, um zu zeigen,
dass also auch sowas wie so ein Zähler,
ein trivialer, ähnlicher Automat ist, Nicht,
wenn ich das Ganze jetzt noch um eine Enable-Leitung ergänze,
das heißt, also ich kann mit Enable gleich eins sagen,
der Zähler soll zählen,
mit Enable gleich null soll der Zähler nicht zählen,
würde dann eben im Zustandsdiagramm so aussehen,
dass ich hier in irgendeinem Zählerzustand bin,
nicht für Enable gleich null, also enable nicht,
hätte ich dann eben hier so eine Rückführung,
wo dann eben in dem Zustand bleibt,
für Enable gleich eins,
gehe ich dann eben in den nächsten Zählerzustand,
das wäre dann eben hier
die zugehörige Flusstafe
Nicht hier jetzt so ein Dreibezähler. Das heißt,
da kann ich dann eben entspannt von 0 bis 7 zählen.
Der hat dann eben Enable und zusätzlich dann noch so was wie Leitung zum Vorwärts- und Rückwärtszielen,
wo ich dann eben sagen kann, wenn Enable nicht aktiv ist,
dann bleibt er sowieso in dem Zustand.
Ansonsten wird eben unterschieden, ob ich Enable oder wenn Enable gleich 1 ist und V gleich 1,
0 vorwärts gezielt werden, wenn Enable gleich 1 ist und vor Ort gleich 0, sondern rückwärts gezielt werden.
Und als Zustandsdiagramm würde das dann eben entsprechend so aussehen. Nicht hier dann ein 5-Bezähler,
ein Reset würde sich dann quasi auswirken, wie das,
was man also hier sieht,
wo es dann also quasi von jedem Zustand dann eben noch eine Kante hierhin in diesen Zustand gibt,
der dann quasi dem Zählerstand null entspricht,
nicht wo ich dann eben sagen kann,
abhängig von der Eingabe Kann ich dann anhalten, vorwärts zielen,
rückwärts zielen, Reset machen und so weiter und so fort.
Also auch solche Sachen sind formal gesehen, erstmal letztendlich nichts anderes als Schaltwerke. Gut,
wenn man das Ganze entwirft, kann man dann dementsprechend minimieren,
irgendwie abbilden, hier dann mit Hades simulieren,
wenn ich jetzt so sie darauf verzichten, also dass wir jetzt,
also hier dann also auch mit den JK-Flip-Props gemacht,
also eine Schaltung für einen 4-Bit-Binärzähler, wo ich dann eben sagen kann,
abhängig von der Eingangsbedingung wird dann eben hier entsprechend gezählt.
Und quasi die Funktionalität des Ziels, das heißt, wann habe ich Überträge,
wird dann eben hier durch die Verknüpfung mit den entsprechenden Gattern realisiert,
die man dann eben beispielsweise aus der Lorit-Minimierung sich raussuchen oder rausrechnen möchte.
Hier dann so ein Vierbett-Binärzähler mit D-Flip-Flops aufgebaut. Und auch da müsste man sich jetzt eben einfach von den Schaltfunktionen her überlegen,
wann Würde dieser Zähler jetzt quasi seinen Wert wechseln,
nicht das niederwärtigste Bit wechselt quasi immer den Wert,
nicht zusätzlich hat dieser Zählzähler dann eben noch so einen Enable-Eingang,
beziehungsweise in diesem Fall ist das dann also dieses C-In hier,
was dann eben dafür sorgt,
dass quasi immer der jeweilige Wert über dieses X-Or-Gata negiert wird,
an den Eingang wieder angelegt wird,
bei den nächsten euren Stufen müsste ich dann also quasi sowas wie so ein Carrie berechnen,
was in diesem Fall dann eben heißt,
jeweils die niederwärtigeren Bits sind, alle.
Eins, genau das ist immer dann der Fall,
wenn hier eine Eins, also auf diesem Ondgatter liegt,
und hier eine Eins, und hier, das heißt,
mit diesen Ondgattern wird dann also quasi dieser kaskadierte Ausdruck gebildet,
der dann dafür sorgt, dass dann eben,
wenn ich es eben einen Zählerzustand von null, 1,
1,
1 erreicht habe,
hier dieses Bit kippt
Und anschließend dann eben als Zählerzustand 1, 0,
0, 0 hier anliegt. Gut, alles,
was dort vorher beschrieben wurde, sind sogenannte Synchronerzähler.
Das heißt, alle Flipflops hier,
also seien das jetzt hier diese D-Flip-Flops,
seien das jetzt hier diese Jörg Carflipflops,
hängen hier an einem gemeinsamen Tagsignal
Die allereinfachste Version, ein Zähler zu realisieren,
ist aber eigentlich eine andere, nämlich ein Asynchroner-Zähler,
beziehungsweise letztendlich ist das andere dann funktional gesehen nichts anderes als ein Taktteiler.
Und zwar beim Asynchronzähler geht der Takt jetzt
nur in das Flipflop mit dem niederwärtigsten Bit
Das erhält dann quasi seinen eigenen Wert, negiert.
Das ist nämlich hier dieser Ausgang dann wieder als Eingangswert.
Das heißt, mit jedem Tag schaltet dieses Flip-Flop von null nach eins.
Und so weiter und so fort. So, und der
Ausgang dieses Flip-Flops ist jetzt das Taktsignal der nächsten Stufe.
Das heißt, hier habe ich jetzt eben wieder ein Teilen,
was mir bei einem Wertewechsel von Null.
Nach eins. Entsprechend den Wert invertiert. Beziehungsweise,
wenn er jetzt vorwärts zählen soll,
muss ich das eben so machen,
dass er quasi jetzt beim Wechsel von eins nach Null den Wert invertiert,
den zuvor gefange ich jetzt also hier an mit Null.
Null, wenn der jetzt hier von eins nach Null wechselt,
wird der wird invertiert und ich halte da eine Eins.
Hier passiert wieder nichts,
habe hier wieder
eine Eins
Dieses Verfahren wird dann quasi einfach eins zu eins weitergeführt.
Das heißt, hier habe ich dann eben auch wieder,
dass der Ausgang dieses Flip-Flops hier reingeht und so weiter und so fort.
Das heißt, letztendlich wird hier der Takt durch zwei,
durch vier, durch acht und so weiter jeweils geteilt.
Nicht das Ganze wäre dann in Hades
Falsches Beispiel. Dieses hier,
wo man jetzt eben sieht,
also hier wird es eben automatisch stark generiert,
da wird dann eben hier durch zwei geteilt,
durch vier und so weiter und hier an der niederwärtigsten Stelle sieht man an eben,
da habe ich den dann entsprechend durch 256 geteilt,
dem zufolge langsam wechselt er dann hier
sein Wert
Gut, so eine Schaltung ist natürlich, weil ich hier jetzt also auch gar keine weitere Logik drin benötige.
Natürlich sehr schön und sehr einfach zu realisieren. Ich habe damit eine maximale Taktrate,
bloß was eben passiert, dadurch,
dass der Ausgang von einem Flip-Frop jetzt quasi hier das Taktsignal der nächsten Stufe ist,
schalten die Flip-Frops dann eben anders als beim Synchronzähler,
nicht wirklich gleichzeitig und deswegen dann eben auch der Name asynchron,
sondern die schalten Letztendlich nacheinander, nämlich jeweils verzögert,
um die Verzögerungszeit eines einzelnen Flip-Flops.
Das heißt, wenn ich jetzt nochmal in die letzte Woche zurückspringe,
wo es also jetzt um die Zeitbedingungen geht, nicht,
das heißt,
es verzögert um dieses TAUFF
Gut, hier dann auch nur Vollständigkeit habe angemerkt und ich also so ein Asynchroner Vierbezähler,
Vorwärtszähler, Rückwärtszähler, wo ich dann eben auch diese Unterscheidung einfach nur dadurch machen kann,
also nehme ich jetzt hier den direkten Wert als Takteingang der nächsten Stufe oder den Negierten werden,
nicht in dem Zuzufolge,
der eine zählt dann eben rückwärts der andere Ziel dann vorwärts.
Also wenn ich jetzt hier nochmal dieses Beispiel von eben Nehme,
ich kann nicht sagen, wenn ich jetzt hier mal getagt habe,
der geht jetzt eben hier vorwärts, zählend,
während hier mit dem negierten Ausgang,
der zählt dann eben entsprechend rückwärts
Gut, andere Zähler, andere Beispiele, hier nur so ein bisschen historisch gesehen.
Also auch da gibt es dann also irgendwelche 74 irgendwas,
ICs, wo ich dann also mit solchen JK-Flip-Flops dann eben auch irgendwelche Zählerschaltungen habe.
Nicht jeder auch so ein Ein-Mann-Zähler,
der hier quasi einen Taktteiler durch zwei realisiert,
dann einmal hier etwas,
wo ich dann also so eine Zustandsfolge von sechs Zuständen durchlaufe,
was dann also letztendlich durch sechs teilen kann.
Und je nachdem, wie man das Ganze dann verschaltet,
kann man dann damit dann auch unterschiedliche vorwärts und Rückwärtszähler realisieren
Wie gesagt, also auf die Logik, wie dann hier diese Ausdrücke zustande kommen.
Das wäre dann im Prinzip dann auch ganz normal, Schaltwerksentwurf.
Das heißt, die Funktion, Zustand, Folge, Zustand aufschreiben,
das aus der Tabelle dann eben entsprechenden KV-Diagramm übernehmen, minimieren.
Und dann hält man eben die jeweiligen benötigten, logischen Ausdrücke. Als ein anderes Beispiel an sowas wie so eine Digitaluhr mit BCD-Zählern,
wo ich dann eben sagen kann,
ich habe jetzt also hier quasi irgendwie sowas wie so einen sechsstelligen BCD-Zähler,
habe hier also irgendwo meinen Takt, ich zähle hier unten,
letztendlich dann die Sekunden von null bis 59,
hier dann eben Minuten von 0 bis 59 und hier dann Stunden von 0 bis 23 und war es dann eben hier in der Logik letztendlich noch mit drin ist,
ist, dass man dann eben sagt,
wenn ich also zum Beispiel hier als Zähler stand,
wie eine Sechs habe.
Das heißt also dann BCD als 0-1-1
-0 kodiert. Mich erzeuge ich dann eben hier
quasi so was wie ein Reset für die Schaltung.
Das heißt, nach dem 59 jetzt sagt er sich dann
wieder seine Null. Und ich habe hier einen Übertrag,
der dann in der nächsten Stelle ein weiterzählt.
Also auch das konnte man jetzt hier ein hartes entsprechend simulieren
und dann eben sehen, wie das Ganze entsprechend raufzählt.
Mal schnell aufgerufen
Falsch geraten. Ja,
ich fand hier war das Ganze jetzt eben entsprechend sekundenweise raufzählen
und wenn der dann also irgendwann bei 59 angekommen ist,
habe ich dann eben hier den Übertrag und erzählt da entsprechend weiter,
so wenn ich das jetzt hier mal so auf Fast stelle,
dann sieht man,
wie er da ist,
also entsprechend hier ist irgendwie passend weiter läuft
Gut, das Ganze deswegen eigentlich die Motivation ist eigentlich
noch Teil so einer etwas größeren Schaltung.
Dazu habe ich hier mal das Ganze als Muster ohne Wert mitgebracht.
Nicht, wofür braucht man sowas? Also da geht es also darum,
eigentlich mal zu zeigen, was also ein bisschen komplexeres Beispiel ist
für einen endlichen Automaten oder für einen ganzen Satz endlicher Automaten ist.
Nämlich sowas wie so eine funkgesteuerte Uhr,
die dann also quasi jetzt mit dem Zeitzeichen-Signal, also dem DCF-77-Signal arbeitet,
wo ich eben sage, ich kriege hier irgendwie mein Zahlsignal.
Da wird letztendlich in diesem Signal, was dort gesendet wird,
pro Sekunde ein Bit übertragen und in einer Minute werden insgesamt 59 Bit übertragen.
Darin ist dann also quasi kodiert für die folgende Minute jetzt
genau der Minuten Stundenwert und das Datum und noch ein bisschen was an Zusatzinformationen,
Prüfbitz und noch ein paar andere Sachen,
wo dann aber letztendlich dann immer gesagt wird, okay,
an dieser Stelle jetzt die nächste Minute hat die und die Werte und die Sekunden muss man dann letztendlich selber mitzählen.
Nicht in das Ganze kann man dann eben auch,
also gibt es dann hier auch als Hades-Schaltung, sagen,
okay, also ich habe letztendlich hier sowas wie so ein Modell von so einem DCF 77-Sender,
habe dann also irgendwo so einen Automaten, der jetzt quasi in das,
was dort übertragen wird, sich einsynchronisieren muss,
der dann eben feststellt, an welcher Stelle in der Übertragung bin ich und das entsprechende Bittern eben auch passend auswertet.
Nicht, wenn das alles richtig übertragen wurde,
wird dann also quasi hier irgendwo eine Zeit gesetzt und das Ganze wird dann eben mit so einer solchen sieben Segmentanzeigen ausgegeben,
das, was dort dann eben letztendlich immer dargestellt wird,
ist dann im Prinzip genau sowas wie dieses Hira,
nämlich so eine BCD-Arrathmetik, wo ich dann eben sage,
mit Fearbit kodiert,
steuere ich dann eben quasi eine Stelle hier in der Anzeige an,
nicht und habe dann eben hier hinten Sekunden Minuten Stunden und kann das Ganze dann eben entsprechend jetzt also irgendwie mir so anzeigen lassen.
Und formal gesehen sind das dann eben viele verschiedene Automaten,
die dann eigentlich zusammenarbeiten, nicht also einer hier, einer hier in irgendwelchen Zählern.
Nicht dieses Ding hat dann natürlich auch noch irgendeine Wegfunktion,
die man einstellen kann und so weiter und so fort.
Was das hier hier eigentlich es interessant macht, ist,
also dass die eigentliche Schaltung jetzt eben wirklich direkt in Hardware realisiert wurde.
Das ist also letztendlich dieser Chip. Alles, was hier sonst noch drauf ist,
ist eigentlich nur irgendwie Ansteuerung oder irgendwelche Treiber jetzt für die sieben Segmentern zeigen,
aber die eigentliche Funktion ist eben wirklich hier in einem einen Chip drin und dann also wirklich komplett in Spezial-Hardware gegossen. Gut,
ist also ein etwas älterer Entwurf,
was auch ein deutlich älterer Technologie noch, davon abgesehen,
dass das natürlich jetzt also nicht die typische Aufgabe für Spezial-Hardware ist,
weil das ist also so unendlich langsam, dass man sagen würde,
nehme ich also irgendwie so einen Mikrocontroller für 20 Cent,
programmiere das quasi in Software auf ein System,
habe die gleiche Funktion, aber um jetzt eben zu zeigen,
wie man also letztendlich dann eben auch sowas jetzt irgendwie entsprechende oder Automaten jetzt wirklich so auf der Ebene,
wie wir sie jetzt hier kennengelernt haben,
dann eben auch direkt in Silizium umsetzen kann.
Gut, nicht, also hier dann nochmal so ein bisschen Skrimatic davon und so weiter.
Mich war es hier dann auch noch mit drin, ist es dann Verfahren,
dass diese sieben-Segment-Anzeige dann eben auch quasi als Multiplex angesteuert wird.
Also ein Problem bei solchen oder bei vielen Schaltungen ist ja immer,
dass man sagt, wenn ich jetzt hier habe sechs,
sieben Segment-Anzeigen, müsste ich hier quasi an ein Ein- und Ausgängen,
ja,
also für jede von diesen sieben Segment-Anzeigen
quasi sieben Leitungen rausführen
Mal sechs habe ich also schon irgendwie 42 Leitungen, die quasi rausgehen, um zu sagen, soll diese LED angehen oder soll sie ausbleiben. Nicht,
wenn ich das jetzt also bei ein bisschen größeren oder bei anderen Ausgängen mache,
dann kostet das eigentlich viel zu viel Ein- und Ausgänge,
die ich also irgendwie jetzt nicht habe oder die also,
gerade wenn man das jetzt also entsprechend Silizium direkt umsetzt,
vergleichsweise aufwendig sind,
war also ein Problem bei dieser Schaltung ist eben schon,
dass man sagen kann, die eigentlich benötigte Schifffläche in der Mitte,
der ist also irgendwie so unendlich klein in heutiger Technologie,
also sowieso noch extremer.
Und das, was eigentlich nur Platz kostet,
sind außen drum irgendwelche Schaltungen, über die dann letztendlich nach außen hin,
also quasi in das Gehäuse, die Drähte oder die Verbindung gehen,
um Ein- und Ausgänge zu realisieren.
Und die sind dann hier quasi rundherum,
um das ganze Ding angeordnet. Das heißt,
hier sind noch welche, hier sind noch welche,
nicht in die Schifffläche wird letztendlich bestimmt durch die Anzahl dieser
Ein- und Ausgänge
Da versucht man jetzt eben zu sagen, okay,
wie kriege ich also jetzt weniger Ein- und Ausgänge hin?
Deswegen die Idee zu sagen, okay,
ich mache jetzt nicht für eine Sieben-Segmentanzeige 7 Leitungen,
sondern davon jetzt entsprechend dadurch,
dass ich jetzt sechs von den Anzeigen habe,
sechsmal Musik Musik Musik Musik Musik At für das Register
und letztendlich diese Berechnungszeit der aufwendigsten Stufe und die Setup-Zeit von
dem Register beschreiten wir quasi an hier die maximal oder die
minimale Periodenlänge
So, und was hiermit jetzt eben angedeutet ist,
ist, dass eben die unterschiedlichen Funktionen unterschiedlich lange brauchen.
Ich den Takt aber letztendlich durch dieses langsamste Teil irgendwann festgelegt habe.
Wenn ich den Takt schneller machen würde, würde hier ein
falscher Wert übernommen werden. Ich habe irgendwelche Verletzungen von Setup-Zeiten
und da passiert also irgendwie was, dass das Ding falsch rechnet.
Auch wenn in 90 Prozent der Fälle das Ganze hier vielleicht alles
irgendwie wunderbar passt, weil die Funktion Eintracht deutlich schneller sind.
Die Idee bei solchen Asynchronschaltungen ist jetzt eben zu sagen,
ich habe Zwischen den einzelnen Operationen jetzt hier noch irgendwelche Zeiten, die ich brauche, um also sowas wie so ein Handshake auszuhandeln. Habe ich am Ausgang gültige Werte,
kann die nächste Stufe damit weiterrechnen, aber wenn das jetzt fertig ist,
kann die dann eben auch direkt loslegen, die Hoffnung nicht,
also sprich, habe ich hier sowas, wo ich Daten anlege,
es gibt ein Request-Signal und es gibt dann so ein Agnolage-Signal,
oder mache ich das so,
dass ich quasi Daten und invertierte Daten übertrage und wenn der Empfänger dann quasi feststellt,
die Werte sind wirklich komplementär zueinander,
dann hat er einen gültigen Wert,
muss dann eben nur ein Agnolage zurückgeben,
um jetzt quasi zu signalisieren,
dass dann eben auch natürlich der Sender hier
eine neue Berechnung weitermachen kann und dann eben entsprechend dann noch
neue Daten erzeugen kann
Ja, kann man jetzt also hier unterschiedliche Methoden sich überlegen, wie dann eigentlich diese Protokolle weiter ablaufen. Nicht,
also sprich, habe ich sowas, was dann also sagt,
Daten ändern sich, nach einem Eck Knowledge,
das Request geht auf eins, das Eck Knowledge beantwortet das,
dann kann also hier das Request zurückgenommen werden und wenn dann das Eck Knowledge zurückgenommen wird,
können die Daten geändert werden, das heißt,
das wäre dann also im Protokollwassersee jetzt hier quasi durch vier Phasen das Ganze steuert oder mache ich das also so,
dass ich eben sage, mit jedem Zustandswechsel für Request beziehungsweise Ferk Knowledge habe ich dann also hier einmal den einen,
hier einmal den anderen Zustandswechsel, der dann eben sagt,
ich kann jetzt entsprechend weiterarbeiten,
dass wir dann eben quasi hier einmal zu Pegel und hier einmal Kanten getrieben.
Da lassen sich dann also verschiedene Beispiele machen,
was man dann auch häufig findet,
ist dann auch so eine Art asynchronische Haltung,
also hier nennt sich Maler Seegate,
das ist dann im Prinzip ja so hier auch so ein rückgekoppeltes Skater,
wo die Eingänge A und B sagen, wenn beide null sind,
wird der Ausgang null, wenn beide eins sind,
wird der Ausgang eins in allen anderen Fällen, bleibt der Wert erhalten,
als Zustands- oder als entsprechendes KV-Diagramm würde das dann so aussehen,
wenn ich das hier entsprechend minimiere, hätte ich dann eben hier das in so einer Norealisierung,
wo ich dann eben auch die Rückkopplung des Zustands Ähm,
von dem, von diesem Maler-Segate dann eben auf den Eingang drin habe.
Nicht, das gibt's dann also auch für drei Eingänge und damit kann man dann im Prinzip so eine Steuerung machen,
mit der ich also wirklich dafür sorge, dass Werte asynchron ablaufen,
ähm, hier als einfaches Beispiel, eine sogenannte Mikropipeline,
ähm, da ist eben die Idee, dass ich sage,
ich habe hier im Prinzip jetzt irgendwelche Ledges und anstatt zu sagen,
jetzt mit irgendwelchen Master-Slave-Steuerungen und zwei Phasentakt werden hier irgendwelche Werte reingeschrieben,
mache ich das dann eben hier über so ein Request und Eknowledge,
was dann eben mit solchen Maler-Seagates aufgebaut ist und als ein Beispiel von dem Ganzen,
wenn man das dann hier in so einer Hades-Realisierung sich ansieht,
Ist das also hier im Prinzip dann folgendes,
also das wäre jetzt hier so ein einzelnes Maler Sea-Gate,
wie gesagt, wenn jetzt beide Eingänge null sind,
ist der Ausgang null.
Wenn beide eins sind, führt der Ausgang auf eins gesetzt.
Und da blagte dann eben auch,
es seien beide Eingänge, gehen wieder auf null,
aber jeweils in anderen Fällen ändert er sich nicht.
So, und jetzt über diese Verschaltung dieser Gates und der
Entwerter hier habe ich jetzt hier folgendes erreicht.
Ich habe hier sowas wie ein Wright, da kann ich
jetzt einzelne Bezieher reinschreiben. Habe hier ein Fool,
das heißt also auf dieser Seite wäre jetzt der Sender.
Hier hätte ich meinen Empfänger, habe ein Riedsignal,
wenn ich einen Wert entnehmen möchte, beziehungsweise ein Available-Signal,
um zu sagen, dass neue Werte da sind.
Hier Stage ist dann quasi einfach nur der Füllstand mit drin.
Und was man jetzt sieht, wenn ich jetzt,
also hier das Right von 0 auf 1 setze,
Diese Pipeline, dann entsprechend so weit voll, dass ich sage,
ich habe hier einen Wert available und sie ist jetzt vor,
jetzt geht das A jetzt hier zurück,
dann habe ich jetzt hier einen Wert reingeschrieben,
hätte jetzt hier einen zweiten Wert reingeschrieben,
könnte jetzt hier einen dritten Wert reinschreiben, jetzt ist die Pipeline auch voll.
Gleichzeitig kann ich jetzt hier Empfängerseitig mit dem Ried hier einen Wert entnehmen,
zweiten Wert entnehmen, wenn ich den dritten Wert entnehme,
hätte ich dann eben hier das Available weg,
beziehungsweise wenn ich das jetzt hier beispielsweise auf zwei Fülle Hier einen raus,
lese, hätte er ihn hier noch entsprechend einen drin.
Also das nur als so ein Beispiel, wie man im
Prinzip jetzt solche Pufferstrukturen oder solche Handshake-Sachen theoretisch realisieren könnte.
Und so was wie würde dann eben beispielsweise dann eben wirklich in so einer größeren Kontext,
in so einer Steuerung von solchen Registern bzw. in der Kommunikationseinheit zwischen irgendwelchen Verarbeitungseinheiten.
Also sprich, hier an diesen Stellen dann irgendwo dazwischen setzen.
Gut, damit ist jetzt dieser Teil zu den Schaltwerken eigentlich
so weit beendet, beziehungsweise überhaupt dieses Kapitel Schaltwerke.
Damit werden wir jetzt also auch die unteren Ebenen der Hardware eigentlich verlassen.
Das heißt, ab Freitag wird es dann Mit der Rechnerarchitektur weitergehen.
Das heißt also, da werden dann jetzt also wirklich mehr Higher-Level-Konzepte im Vordergrund stehen.
Das heißt, was verstehen ohne da Rechnerarchitektur,
welche Komponenten sind da sonst noch eingesetzt,
um dann also letztendlich den Übergang zu machen zu befehlen,
Befehlsabarbeitung, wie wir sie dann eigentlich im von Neumann-Konzept mit drin haben.
Das heißt also, hiermit ist jetzt eigentlich so dieser Teil Schaltnetze, Schaltwerke abgeschlossen.
Nicht hier kommen jetzt nochmal so ein bisschen komplexere Hardware-Elemente,
also sprich Busse und Speicher mit dran,
aber anschließend geht es dann eben mehr jetzt um die Schnittstelle zur Software bzw. zum Betrieb von Rechnern.
Gut, also wie gesagt, damit geht es dann
ab Freitag weiter und dann bis dahin tschüss