So, ja, heute an ungewohnter Stelle mit etwas kleineren Hörsaal,
aber da sich die Zuhörerschaft leider schon gelichtet hat,
passen wir hier also auch noch problemlos rein.
Ansonsten, wie gesagt, das ist also heute der Ausnahmefall,
ab nächster Woche ist dann Freitag wieder wieder gehabt, dann drüben im Rechtshaus.
Ja, ich hatte ja aufgehört, Mittwoch mit der Vorstellungen oder Möglichkeiten,
wie man jetzt also Schaltwerke, sprich endliche Automaten,
wenn sie jetzt in Hardware realisiert werden, beschreiben kann. Und dabei,
also erstmal sagen wir, die einfachste Variante vorgestellt,
nämlich Flusstafel und Ausgangstafel, was also letztendlich nichts anderes ist,
als einfach für die Zustandsübergangsfunktion bzw. für die Zustands,
für die Ausgabefunktion, abhängig von den Zuständen,
dann eben einfach die Funktionstabellen aufzustellen und dann würde man eben entsprechend,
wie wir das da sehr auch schon vorher bei den Schaltwerken gemacht haben,
wie das jetzt ja also auch in den Übungsaufgaben dran war,
dann entsprechend Anfang die Funktion dort rauszunehmen,
in KV-Diagramme beispielsweise einzelne Fragen zu minimieren und das Ganze dann dementsprechend zu entwerfen.
Als zweite bzw. grafische Möglichkeit von Beschreibungen haben wir also auch schon sogenannte Zustandsdiagramme gesehen,
wo man sagen kann, ich habe im Prinzip Knoten,
jeder Knoten entspricht dann quasi einem einzigen Zustand.
Ich habe dann von einem Zustand in einen anderen Zustand oder
in einen Folgezustand eine Kante und abhängig von den Eingabebelegungen,
unter denen dann also quasi der Zustandswechsel stattfindet,
wird dann eben entsprechend diese Kante durchlaufen,
beziehungsweise dazu wird dann eben logischerweise dann eben die Eingabe an der Kante entsprechend notiert.
Bei den beiden Arten von Beschreibungen für Endliche Automaten,
hatte ich ja gesagt, gibt es also einmal das Murr-Modell,
wo die Ausgabe jetzt eben nur direkt vom Zustand abhängig ist.
Das, was, sagen wir mal, so rumgesehen immer das etwas einfachere Modell ist.
Dort wird dann also im Prinzip die Ausgabe einfach jetzt,
weil die dann ja am Zustand hängt,
einfach in den Knoten mit rein notiert. Während beim Millimodell,
wo die Ausgabe quasi von Zustand und Eingangsvektor abhängig ist,
wird dann eben der entsprechende Ausgangswektor dann eben an die
jeweilige Kante geschrieben,
die also
diesen Zustand verlässt
Dann letztendlich hat man dadurch dann die Unterscheidung,
wo das dann abhängig von der Eingabe dann noch passiert.
Gut, wie sieht sowas rein? Praktisch aus,
dass ich hier mal ein,
gut, ich sag jetzt mal sinnfreies Beispiel, nein,
aber falls mal irgendwie ein Beispiel, wo man also sieht,
wie sieht so ein Murautomat aus?
Also wie gesagt,
in den Zuständen hätte ich dann also hier mögende Beschreibung des Namens,
überhaupt,
wenn ich das mache und dann eben die jeweiligen Ausgangswerte an
den Karten steht dann eben letztendlich die Eingangsbedingungen dran,
unter der der Zustand
dann eben verlassen wird
Ne, und das Ganze ist dann eben so zu interpretieren,
dass man sagt, okay,
ich muss ja dann eben sowas wie ein Marker oder ein Token dann denken,
wo ich dann eben sage, okay,
das ist jetzt hier mein aktueller Zustand,
also beispielsweise jetzt hier Zustand A, die Ausgabe ist,
000 und wenn jetzt eben die Eingabe X gleich eins habe,
würde dieser Automat eben den Zustand B wechseln,
wenn ich die Eingabe X gleich 0 habe,
würde diese Automate in den Zustand zielwechseln und dann eben
die Ausgabe jeweils den Wert annehmen,
der dann also hier in dem Zustand notiert ist
Was sie jetzt also nicht mit eingezeichnet ist,
war es aber eigentlich auch immer noch wichtig ist.
Ich habe ja gesagt, also Automat als sechs Tupel.
Es gibt immer noch einen ausgewählten Staatszustand. Möchte man sinnigerweise natürlich auch haben,
weil wenn ich jetzt sage, okay, was passiert,
wenn ich hier um ein Gerät einschalte oder wenn irgendwas in Betrieb genommen wird,
wo laufe ich los?
Dazu wird das dann also in diesen Grafiken dann immer typischerweise dadurch gekennzeichnet,
dass man dann eben, ja,
also irgendwie die Umrandung verzeichnet oder noch einen zweiten Kreis drumherum
oder hier eben irgendwie so ein Segment dieses Kreises
dann,
also quasi entsprechend ausgefüllt zeichnen würde
Mili-Automat würde so aussehen, also auch hier jeweils die Zustände,
aber ich habe dann eben an den Übergängen eben die jeweiligen Ausgangsvektoren,
nicht und das Ganze ist dann eben so zu lesen,
dass ich sage, okay,
ich bin in Zustand A,
Eingabe ist x gleich 1 und dann würde dann eben als Ausgabe 100 erfolgen und der Automat in den Zustand B übergehen,
während bei der Eingabe X gleich Null,
dann eben die Ausgabe 1-1-1-Sphäre und der automatischen Zustandszee übergeht.
Gut, also wie gesagt, das eigentlich relativ einfach selbst erklären.
Erweiterte Automaten, die es eigentlich also auch schon seit
längerer Zeit gibt, sind dann das sogenannte Stageharts.
Werden wir jetzt, also hier nicht weiter betrachten.
Ich werde aber dann nachher nochmal einige Beispiele dazu vorstellen,
beziehungsweise diejenigen von ihnen, die dann also vielleicht nochmal irgendwann sowas wie eingebettete Systeme später hören.
Dort wird das dann also auch noch ein bisschen genauer betrachtet. Das sind im Prinzip jetzt noch mal Erweiterungen dieser Automatenmodelle,
also auch so eine entsprechende grafische Beschreibung,
wo man dann aber eben zusätzlich noch die Möglichkeit hat,
Hierarchien mit reinzubringen, nicht weil,
also sagen wir mal so ein endlicher Automat,
wenn ich den jetzt also so in Form von Zuständen und irgendwelchen Übergängen beschreibe,
nicht also irgendwann, wenn ich ein entsprechend größeres Problem habe,
wird das Ding natürlich also beliebig unübersichtlich.
Und wenn man da jetzt also hierarchische Ideen mit reinbringt und sagt,
okay, ich kann erst mal grob unterscheiden,
bin ich in dem oder dem oder dem Grundzustand oder Grundfunktionalität und dann eben genauer reingucke,
was befindet sich dann eben innen drin.
Jetzt also als Automat und als Ablauf da mit drin.
Nicht, das kann man dann eben dort entsprechend mit modellieren. Dann ein entscheidendes Konzept,
was also jetzt hier in den endlichen Automaten,
was man noch nicht drin ist, wie sie das mit Nebenläufigkeiten aus,
wenn ich jetzt also quasi sowas habe, wie gekopelte Prozesse,
die aber eben wirklich unabhängig voneinander irgendwie was tun.
Nicht, dann ist natürlich die logische Idee, dass man sagt,
okay, also jeder einzelne Prozess wird durch einen Automaten beschrieben.
Auch das ist dort letztendlich irgendwo dann formalisiert. Und dann gibt es eben noch die Möglichkeiten,
also das, was das Ganze dann jetzt wieder so für eingebettete Systeme interessant macht,
dass man dort dann eben auch noch Möglichkeiten hat,
so was wie Timer zu beschreiben, das heißt sagen kann,
okay, ich bin in einem bestimmten Zustand
Wenn jetzt die und die Eingabe passiert, dann wechsle ich den Zustand.
Wenn es aber irgendwie dieses Eingabeereignis nicht stattfindet,
kann man eben sagen, dann wird dieser Zustand nach der
und der Wartezeit eben auch automatisch verlassen.
Also wie gesagt, das ist da dann eigentlich vergleichsweise beliebte
Spezifikation das Ganze. Also auch nicht zwingend neu,
wurde ursprünglich 1984 von David Harrell entwickelt
Ja, ein paar Jahre später dann allerdings auch erst veröffentlicht. Wie gesagt, hier ist er nochmal so ein Querverweis, also auf das Original-Paper. Nicht,
da findet sich dann unter anderem,
also dieses Beispiel einer, ja, sag mal,
Mitte oder Ende der 80er Jahre recht beliebten Digitaluhr eines japanischen Herstellers,
wo im Prinzip genau dieses Verhalten oder eben diese Beschreibungsform,
also letztendlich benutzt wurde, um jetzt eben diese Funktionalität zu modellieren,
wo man eben sagt, okay,
also ich bin in einem Zustand,
wo ich jetzt eben sage, okay,
also ich möchte jetzt also hier durch irgendwelche Tasten Kombination oder Tasten drücke jetzt also irgendwie die Zeit einstellen.
Nicht das heißt, dann gehe ich jetzt erstmal irgendwo diesen Set-Modus,
wenn ich in dem bin und jetzt also die Taste B drücke,
dann soll das und das passieren.
Und das wird dann eben über solche Stage-Charts,
also solche hierarchischen Beschreibungen, also das ist dann, wie gesagt,
hier nur ein ganz kleiner Ausschnitt von dem Ganzen dann eben entsprechend formal beschrieben.
Nicht aber letztendlich verbirgt sich dahinter,
also wenn man dann hier weit genug reinguckt,
dann eben auch nur sowas wie so eine endliche Automat,
wo man sagen kann, ich bin eben den Zustand,
wenn da was gedrückt wird,
dann wechsle ich eben in den entsprechenden anderen Zustand
Hier auch nur noch mal kurz der Hinweis, generell dieses Grundkonzept,
endliche Automaten, ich weiß jetzt nicht, inwieweit das jetzt,
also vielleicht schon irgendwo in der Theorie oder in der Softwareentwicklung angesprochen wird,
ist eigentlich irgendwo so eins der Standardkonzepte in der Informatik,
was also jetzt nicht nur hier irgendwo im Zusammenhang mit der Hardware oder dem Hardwareaufbau bzw. im Betrieb von Rechnern letztendlich benutzt wird,
sondern was eigentlich bei relativ vielen Beispielen, also Compilerbau,
Theorie, irgendwelche autonom arbeitenden Systeme und,
und, und, Protokolle.
Auch ein beliebtes Beispiel, dann also eigentlich ständig benutzt wird.
Ich war mit Dame dann eben eigentlich sehr gut das Verhalten
modellieren kann und eben dann eben in Form von solchen Abläufen auf dem Automaten dann eben auch entsprechend simulieren kann.
Und letztendlich das, was da ja dann sich dahinter verbirgt,
ist eben genau diese Abfolge von irgendwelchen Systemzuständen,
sowas wie Diese bedingten Zustandswechsel, das heißt eben die Reaktion auf irgendwelche Ereignisse,
sei das jetzt eben irgendein Tastendruck oder sah das,
wenn ich jetzt also wirklich in die Hardware gehe, also irgendein Interrakt von irgendeiner Einheit, was weiß ich auch immer.
Nee, in dem Zufolge hat man da eben eine sehr viele Anwendungsszenarien,
also fatale Systeme, Echtzeitsysteme, eingebettete Systeme und so weiter und so fort.
Ich habe hier nun mal auch grob völlig unterschiedliche Beispiele mal so zusammengetragen.
Also dieses ist hier quasi Programmierung,
beziehungsweise eigentlich sowas wie Compilerbau und nicht, also wo ich sage,
okay, Ich möchte jetzt einen bestimmten String oder ein bestimmtes Wort Pasen oder erkennen.
Nicht, dann kann ich das eben automatentechnisch eben einfach so realisieren,
dass ich sage, ich habe hier meinen Staat zu Start, er ist null. Nicht,
wenn jetzt A, B, A erkannt werden soll, nicht,
dann würde ich eben jetzt beim Durchlaufen dieser drei Zustände eben hier in diesem Endzustand S3 landen,
in allen anderen Folgen, lande ich eben in einem Zustand S4,
der mir dann eben letztendlich sagt, ja, sorry,
der ist jetzt ein anderer String gekommen.
Also ist ein Trivialbeispiel, aber letztendlich also auch im Compiler war,
wo es jetzt darum geht, also dieses jetzt hier nicht einzelne Buchstaben,
sondern eben zum Beispiel Schlüsselwort, eine Programmiersprache,
wird also genau sowas letztendlich umgesetzt, nicht wo man sagt, okay,
also ich habe jetzt das und das gepasst, eben anschließend darf jetzt von der Syntax her nur der oder der oder der String kommen. Also auch da würde man solche Konzepte letztendlich genauso umsetzen. Anderes Beispiel,
Game Design, in Anführungszeichen künstliche Intelligenzen haben,
ist es nicht, nicht er war sehr,
also wir befinden uns also hier in irgendeinem Rollenspiel,
also da ist jetzt irgendwie so ein Bot,
was macht er typischerweise, der rennt also irgendwo munter durch die Karte,
wenn der Spieler in der Nähe ist, dann soll er den angreifen,
wenn der Spieler nicht mehr in der Nähe ist,
dann soll er eben weiter irgendwie zufällig durch die Karte laufen,
wenn der Spieler jetzt also irgendwie auf die Idee kommt,
sich zu verteidigen, na gut, dann soll der Wort natürlich abhauen,
weil im Zweifelsfall hat sich der Spieler irgendwie hochgelevelt und würde dann Wort also irgendwie entsprechend für nicht,
nicht, also irgendwie entsprechend abhauen, wenn der Spieler jetzt also irgendwie sagt,
okay, ich verteidige mich nicht mehr,
dann natürlich weiter angreifen und ansonsten kann man eben sagen,
okay, wenn jetzt irgendwie dann schon zu viel Energie verloren,
hartnächtern, soll er natürlich also erstmal zusehen,
dass er sich selber erst mal wieder entsprechend mithilfe versorgt und dann eben das Ganze wieder von vorne losgeht.
Gut, also es ist doofes Trivialbeispiel,
nicht aber einfach nur mal,
weil also auch dahinter steckt eben letztendlich so ein Konzept von endlichen Automaten,
also ich bin in dem Zustand,
das und das passiert,
wie reagiere ich da drauf
Anderes Beispiel, typisch oder klassische kleinen Serverarchitektur. Das ist also
auch hier so eine Beschreibung einer beratgestellten Bibliothek, die also im Prinzip zu dem Ross-System gehört.
Ross steht für Robert Operating System. Das ist also das,
womit wir bei Tumbs beispielsweise arbeiten, wenn wir sagen,
also wir machen jetzt also hier irgendwie Robotik, haben irgendwelche mobilen Plattformen,
die durch die Gegend fahren, irgendwelche Objekte meinetwegen hier vom Tisch greifen und mir bringen sollen oder irgendwie sowas machen sollen. Also da gibt es dann eben auch an Infrastruktur,
also relativ viel eben auch schon an vorgegebenen Bibliotheken,
womit dann also quasi diese ganzen primitive, sprich,
wie unterhalte ich mich mit der Hardware,
wie sage ich der Plattform, sie soll von A nach B fahren,
da möchte ich jetzt also nicht dem Motor sagen,
fahre so und so viele Radumdrehungen,
sondern ich habe sowas wie eine Karte und sage, mache das,
denn das Ganze läuft dann eben auf so einer verteilten,
planen Serverarchitektur und also auch da ist es dann eben so,
dass man sagen kann, okay,
der Client sendet dann eben irgendwie an den Server irgendwelche Aktionen,
die diese ausführen soll, Wenn die Ressourcen da ist,
wird das eben entweder ausgeführt oder landet eben noch irgendwo in einer Warteschlange,
demzufolge, je nachdem, was sich da dann eben passiert,
ob der Client die Aktion abbricht oder ob das Ganze dann eben irgendwie versucht wird, erfolgreich oder vielleicht auch nicht erfolgreich, gibt es da dann eben entsprechende Meldungen.
Genauso gibt es dann eben auch für den Client dann,
also im Prinzip so eine Beschreibung nicht.
Und auch hier sieht man also sowas wie so ein Automatenmodell mit Zuständen,
mit Aktionen, die dann eben quasi da Übergänge beschreiben,
ist da also auch und gebe.
Und damit kann man dann eben auch vergleichsweise komplexe Verhaltensweisen mitbeschreiben.
Hier auch aus der Dokumentation einer anderen Bibliothek, die also
auch relativ viel in verschiedenen Programmierprojekten oder Umgebungen genommen wird.
Also diese Bußbibliotheken. Und da gibt es dann eben unter anderen dann eben auch eine,
wo dann eben auch direkt solche Stage-Charts beschrieben werden.
Also hier, das ist also jetzt Ausschnitt eines Beispiels,
wo es also im Prinzip um eine Digitalkamera geht,
nicht wo ich dann sagen kann, okay,
ich habe jetzt eben erstmal so als grob getrennte Zustände.
Ich nehme ein Foto auf und ich nehme eben kein Foto auf und das Ding ist eben erst mal im Zustand eidel,
wenn man jetzt eben anfängt, den Auslöser halt durchzudrücken,
dann wechselt er eben in den Zustand,
es soll das Foto aufgenommen werden, das System versucht zu fokussieren,
wenn das erfolgreich ist,
könnte der Sensor aufnehmen und das Ganze speichern und so weiter und so fort.
Also das heißt also auch hier im Prinzip sowas,
wo das Ganze sehr schön eigentlich
so durch solche endlichen Automaten beschrieben werden kann
Analog dazu gibt es dann eben auch sehr viele Entwurfs- und Programmierhilfsmittel,
die das also unterstützen,
die dann eben beispielsweise in Form von solchen grafischen Darstellungen,
die man dann eben entsprechend eingeben kann, also das erlauben,
dass man da eben sein System oder sein Systemverhalten spezifiziert,
das dann eben in Form so einer Simulation durchspielt,
um dann eben zu gucken, verhält sich das so,
wie ich das haben möchte.
Und wenn das ist, kann man daraus dann eben
entsprechend dann auch seinen Code generieren lassen
Also das wäre hier so ein Beispiel für so ein,
in diesem Fall kommerzielles Produkt, was man dann also nehmen kann,
um solche endlichen Automaten zu beschreiben.
Gut, wie gesagt,
hier bei uns wird das jetzt also eher so aussehen,
also deswegen hier unten oder noch Mathe, der Kommentar,
dass wir jetzt also hier natürlich eher so ein bisschen einfacher und hardwarenah sind.
Nicht, also das heißt,
also jetzt kein elaboriertes Verhalten von irgendwelchen Bots beschreiben,
sondern also wirklich nur ganz einfach Zustandsübergänge bzw. endliche Automaten,
nicht so
die klassischen einfachen Beispiele dazu
Hatte ich dann ja eben teilweise auch schon vorgestellt, ja.
Andere Möglichkeiten, das Verhalten von Automaten beziehungsweise Chartwerken zu beschreiben,
wären dann sowas wie Textuelle Beschreibung, also Hardware-Beschreibungssprachen.
Letztendlich ist das dann nichts anderes als eine Art Programmabablauf,
wo man dann eben sagen kann,
also das und das soll passieren,
dort sollen Werte gespeichert werden,
dort soll das
und das berechnet werden
Kann man natürlich theoretisch also auch mit ganz normalen,
beliebigen Programmiersprachen machen, also C oder Java, häufig,
wenn man dann also wirklich daraus Hardware machen möchte, hat man dann irgendwie noch bestimmte Erweiterungen.
Also dazu gibt es dann zum Beispiel sowas wie System C,
was eigentlich C Plus Plus ist und wo man dann also eine beschwimmte Syntax einhalten muss,
wo man dann aber sagen kann, also daraus kann ich dann mit entsprechenden Werkzeugen,
also auch direkt den Hardwareentwurf füttern,
oder man nimmt eben gleich Hardwarebeschreibungssprachen wie Very Lock oder VHDL.
Und alles, was diese Sprachen dann eben auch können oder gemein haben,
ist, dass man eben sagen kann,
also ich habe als Grundkonzepte eben schon mal irgendwie sowas wie Parallelität direkt mit drin,
weil das brauche ich natürlich zwingend, weil wenn ich jetzt sage,
ich habe hier eine Registerbank in meinem Prozessor mit drin und dort eine Alu mit drin,
dann funktionieren die in dem Sinne natürlich erstmal unabhängig voneinander und machen was.
Und okay, wenn ich jetzt sage,
ich möchte natürlich jetzt also rechnen, es soll ein Befehl ausgeführt werden,
der jetzt also irgendwie zwei Operanten aus der Registerbank lädt,
das durch die Alu schleift und das Ergebnis wieder woanders in der Register der Bank ablegt,
dann ist das also etwas, was man dann,
also letztendlich von der Funktionalität her auf diese Hardware abbilden kann,
aber grundsätzlich sind diese Grundkomponenten, sprich das Schalt, Netz,
Registerbank und das Schalt, Blödsinn, das Schalten jetzt,
Alu und das Schaltwerkregister Bank,
also letztendlich erstmal unabhängig voneinander.
Gut, Hardware-Beschreibungssprachen, wenn wir jetzt also hier nicht weiter kennenlernen,
weil das würde dann doch ein bisschen zu speziell sein,
also hier nur mal so kurz als diese so eine Beschreibung,
wie sowas aussieht, also ich hatte ja
In der letzten Sitzung, also ja, sprich vorgestern,
schon kurz vorgestellt, wie im Prinzip so ein D-Flip-Frop jetzt irgendwie so aus Gattern zusammen aufgebaut ist.
Hier wäre also ein D-Flip-Frop jetzt in der Hardware-Beschreibungssprache.
Very Lockman modelliert. Generell kann man immer sagen,
in diesen Hardware-Beschreibungssprachen, man hat immer so eine Trennung zwischen der Interface-Beschreibung,
das heißt, welche Leitung gehen rein bzw. komm raus
Und der internen Realisierung, nicht in Very Lock sieht das dann eben so aus,
dass ich sage, ich habe hier ein sogenanntes Modul,
das hat einen bestimmten Namen, hier jetzt irgendwelche Leitungen,
die da rein und raus gehen.
Hier wird unterschieden, in welche Richtung. The Out soll dann
eben noch so was wie so ein speicherndes Verhalten haben und die ist hier innen drin,
ist jetzt quasi so was wie ein einzelner Prozess,
der dann eben sagt, jedes Mal,
wenn ich eine Taktvorderflanke habe oder wenn das Reset-Signal sich ändert,
rechne ich diesen Prozess durch und im Falle eines Reset-Signals wird er der Datenausgang eben auf Null gesetzt.
Im Fall der Taktvorderflanke, was dann quasi das Elz wäre,
zu dieser Bedingung wird der Datenordnung auf den Dateneingang gelegt.
In VHDL sieht das ein bisschen anders aus,
ist aber im Prinzip eigentlich das Gleiche.
Also hier ist dann nochmal ganz streng so eine Trennung zwischen Interface-Beschreibung,
das nennt sich dann dort Entity und der internen Realisierung,
in dem Fall dann also Architektur
Und ich habe dann eben hier einen Prozess, der Winnery
Set Live 1 ist, den Datenausgang auf null zuweist.
Ansonsten war der Tag vor der Flanke den Datenausgang,
auf den Daten heilen kann. Gut nicht. Und
das liest sich jetzt eben wirklich schon so wie irgendwie,
ja, einfache Imperative Programmiersprache. Und okay,
wenn ich da jetzt so ein bisschen mehr beschreibe als jetzt nur Datenausgang gleich Daten eingangs,
sondern da kann ich dann eben auch schreiben,
die in plus und noch irgendwelche Bedingungen und alles Mögliche mit reinschreiben bekommen hat,
also mit sowas,
also auch eine
relativ kompakte Beschreibung hin
Wo man dann eh wirklich sagen kann,
also was wie so einen einfachen Prozessorkern,
was dann also im Prinzip so ein Klassenkleinen von Neumann-Rechner entspricht,
ist, sagen wir mal so, in 150,
200 Zahlen, also maximal letztendlich machbar.
Gut, ja, dann arbeitest du mal wieder also
zurück zu dem Schaltwerksentwurf. Generell, wie ist also
der Ablauf? Als erstes würde man das Verhalten spezifizieren.
Ich sah das jetzt also irgendwie textuell durch irgendeine harte Beschreibungssprache,
sei das grafisch durch so ein Zustandsübergangsdiagramm, beziehungsweise analog dazu,
dann eben durch die entsprechenden Tabellen,
die dann also spätestens im zweiten Schritt logischerweise folgen würden.
Dann würde man eben sagen, okay,
wie viele Zustände brauche ich? Wie kodiere ich die?
Und anschließend würde man dann eben ganz normal seine Schaltnetze minimieren
und das Ganze eben wirklich in Hades eingeben
Und hätte das dann dementsprechend fertig. Gut gegebenenfalls,
deswegen hier nur der Hinweis, braucht man da dann eben auch noch mehrere Iterationen,
weil so liest sich das natürlich immer wie so ein Kochrezept.
Ich mache jetzt das, mach das, mach das, mach das.
Danach ist man fertig. Wenn ich sage, okay,
das war es dort als Schaltwerk entworfen werden soll,
ist jetzt also wirklich irgendwie sowas wie ein kleiner Prozessorkern,
dann ist es also jetzt nicht mehr so ein triviales Beispiel,
wie jetzt also irgendwie so eine Ampel, die rot-gelb-grün mal irgendwie durchschaltet.
Da wird man dann also schon irgendwann später vielleicht nochmal feststellen,
oh Mensch, da habe ich mich irgendwo vertan oder irgendwas
funktioniert so nicht,
müsste man dann
nochmal entsprechend anfangen
Gut, hier auch noch mal kurz ein Beispiel über die Möglichkeiten,
beziehungsweise die Auswirkungen, die sich also aus der Zustandskodierung ergeben können.
Weil die einfachste Idee, die man natürlich immer hat,
wenn man sagt, okay, ich habe jetzt den Automaten,
da sind es also irgendwie vier Zustände drin,
also fange ich die einfach an,
die näher mit zwei Bit von 00 bis 11 irgendwie durchzunummerieren.
Nicht damit hat man natürlich also
minimale Zustandsanzahl
Es werden aber häufig, also auch beliebig andere Codes genommen,
beziehungsweise letztendlich ist man frei, wie man die Zustände darstellen möchte.
Dazu folgt also auch gleich noch ein kurzes Beispiel,
was eigentlich nochmal so motiviert, warum es vielleicht also gar nicht so gut ist.
Also jetzt immer nur diese minimale Kodierung, binär durchgezählt zu nehmen,
sondern also auch andere Kodierungen, also sinnig sein können.
Ja, also man kann theoretisch im Prinzip sowas wie einschrittige Codes nehmen.
Häufig hat man sogenannte One-Hot-Kodierungen, das war also,
nicht wenn man war, so nochmal irgendwie jetzt an
Ich glaube, Kapitel 5. Zurückdenken, sowas,
wo ich dann im Prinzip so einen entsprechenden String habe und dann eben nur ein einzelnes Bit beispielsweise gesetzt ist.
Also auch das hat bei einigen Sachen eben einigen Charme und letztendlich,
wenn man jetzt also bestimmte Anwendungen im Hinterkopf hat,
kann es eben auch sinnvoll sein, also entsprechend also auf diese Anwendung schon,
also eine bestimmte, wenn auch nicht minimale Kodierung zu nehmen.
Gut, in der Regel sieht das so aus,
dass man Jetzt bei solchen Beschreibungen, dass das dann eben noch durch entsprechende Entwurfshilfsmittel unterstützt wird. Das heißt,
wenn man so einen grafischen Editor hat,
wo man jetzt also einen endlichen Automaten eingibt, also sprich so was,
hier benenne ich ja meine Zustände nur irgendwie und hinterher,
wenn das Ganze dann eben wirklich irgendwo eine Hardware umgesetzt werden soll,
gibt es da dann eben die Möglichkeit, also hier dann auszuwählen,
wie die Zustände kuliert werden sollen, um dann eben zu gucken,
was jetzt vielleicht günstiger oder nicht so günstig ist.
Bei Hardwarebeschreibungssprachen, Hier wird das in der Regel so gehandhabt,
dass sich dort also auch keine Zustandskodierung jetzt also irgendwie fest als Bitmuster eingebe,
sondern man macht das so, wie man das eigentlich in der Programmierung auch sinnigerweise machen würde.
Man deklariert sich irgendeinen Aufzählungstyp, gibt den Zuständen irgendwelche sprechenden Namen. Und hinterher,
wenn ich dann so ein Modell in beispielsweise dann,
also ein Werkzeug rein lese,
war es jetzt also aus so einer VDL-Beschreibung dann eben beispielsweise programmierter Zahlen von FPGA generiert,
dann gibt es da eben die Auswahl zu sagen,
ich möchte das so oder so oder so kodiert haben,
beziehungsweise man kann dann eben bestimmte Randbedingungen einstellen,
möglichst klein oder möglichst schnell und das Werkzeug wird dann eben entsprechend versuchen,
eine, in Anführungszeichen, optimale Lösung zu finden.
Gut, welche Probleme können jetzt generell erstmal bei dem Entwurf auftreten,
wenn ich jetzt das anfange,
Mädels, also irgendwelche Automaten mit Zuständensübergang oder Zustandsübergängen,
also irgendwo aufzuzeichnen
Zum einen muss natürlich also irgendwo gewährleistet sein, dass wir
überhaupt erstmal alle Eingangsbelegungen und Zustände also richtig berücksichtigt werden.
Dann muss man sich jetzt überlegen, gibt es so ein Care-Therme?
Sind die da also auch richtig mit drin? Oder habe
ich da also irgendwelche widersprüchlichkeiten? Also das ist das,
was also häufig auftritt, was man also letztendlich mehrere von
einem Zustand unter einer Eingangsbelegung letztendlich mehrere mögliche Übergänge zur Verfügung hätte.
Das würde dann eben letztendlich zu Widersprüchen führen. Und dann
hat man eben nicht mehr einen deterministischen, endlichen Automaten,
sondern dann hätte man dann Zufälligkeiten, nicht die Terminismus mit drin.
Das funktioniert hier dann, also zumindest so erstmal nicht.
Und was man natürlich dann also auch irgendwo gewährleistet haben möchte,
ist, dass dann auch wirklich alle Eingangsbelegungen berücksichtigt werden. Also sprich,
dass ich dann eben auch eine vollständige Beschreibung habe,
weil alles, was oder das,
was ich jetzt hier an Diesen Beispielen härte ist also zumindest schon mal also irgendwie nicht so richtig vollständig,
nicht beziehungsweise da sind dann eben schon so einige Mehrdeutlichkeiten mit drin.
Also dies Modell würde zwar immer noch funktionieren,
nicht wo ich dann eben sage, okay,
also hier ist es Ganze jetzt nur von x abhängig und unabhängig von Y nicht,
aber das ist dann eben letztendlich hier dann auch schon irgendwo implizit mit drin,
nämlich dieses A1, hier steht dann eben dafür, dass es ein unbedingter Übergang ist,
das heißt den Zustand B würde ich eben immer verlassen und so weiter und so fort.
Und eigentlich müsste man dann eben jeweils für die Automaten dann also wirklich prüfen,
ob das dann eben auch alles diesen Bedingungen genügt.
Dazu kann man folgende vorne nehmen,
also zum einen Vollständigkeit kann ich dadurch überprüfen,
dass ich sage,
wenn ich jetzt also meine Menge an Zuständen habe,
P-Stück an der Zahl und ich habe insgesamt dann eben eine Menge von bis zu zwar auch P-11 kannten,
wobei eine Kantrin ihm immer so gekennzeichnet ist,
dass die dann also quasi den Knoten-I mit dem Knoten-Jord unter
der A-Eingabe
X verbindet
Dass die Vollständigkeit eben genau dann gegeben ist,
wenn für jeden Zustand gilt, dass eben die Desjunktion über
alle Kanten aus diesem Zustand heraus gleich eins ist.
Und widerspruchsfreiheit wäre, dass ich also quasi jetzt alle Kanten,
die den Zustand verlassen, paarweise Unverknüpfe.
Das ist das, was hier dann ist. Und das
dann eben entsprechend zusammen Null ergeben muss. Das heißt,
entweder der oder der Übergang, aber die haben eben keine gemeinsamen Therme.
Und das muss dann eben jetzt wirklich für alle Paare von Kanten gelten.
Gut, also dieses hier wäre jetzt das Ganze mathematisch aufgeschrieben.
Also ich denke mir, das wird jetzt hier bei
dem Beispiel gleich Klarer, was damit gemeint ist.
Also wir haben hier auch so einen Talausschnitt,
so eines Deal Rahmens, haben wir also den Knoten A.
Wir betrachten jetzt erstmal Reason A einen Knoten.
Und es gibt drei Kanten unter der Bedingung X1,
gehe ich nach B, X1 nicht und X08 C und X1 nicht nach D.
So, wie sieht das mit der Vollständigkeit aus?
Da musste ich jetzt eben alle kannten,
hier entsprechend disjunktiv verknüpfen,
erhalte als Ausdruck
dann eben eins
Das heißt, das Ganze ist vollständig, wie Sie das mit der Widerspruchsfreiheit aus.
Paarweise werden die dann eben immer mit einer Unverknüpfung,
quasi als Bultschim-Term durchgerechnet. Nicht, das heißt,
X1 und X1 nicht. Und X0 ist gleich null,
X1 und XA ist nicht, ist auch gleich null.
Wenn ich aber diese beiden nehme, nicht,
also unschwer zu erkennen ist, kann ich natürlich,
wenn X1 nicht Also X1 gleich null ist und X-0 gleich eins ist,
gilt sowohl diese Kante als auch diese Kante.
Das heißt, da wären dann eigentlich beide Übergänge aktiv.
Das heißt also, dieser Graf wäre dann eben nicht widerspruchsfrei.
Das heißt, also damit sollte man also gar nicht erst weiter arbeiten.
Gut, das müsste man dann eben wirklich jetzt jeweils Vollständigkeit,
Widerspruchsfreiheit dann eben für alle Knoten und alle Kanten aus diesen Knoten
an ihm jeweils entsprechend prüfen
Gut, also das nochmal so zu den formalen Methoden,
die man dort einsetzt. Anschließend folgen jetzt also am Rest
dieses Kapitels, also noch einige hochkomplizierte elaborierte Beispiele.
Zum einen anhand dieses Beispiels Verkehrsampel,
würde ich also nochmal kurz so ein bisschen was zu der,
diese Thematik mit der Zustandskodierung vorstellen.
Nicht dann werde ich nochmal ein bisschen was zu Zählern sagen
und dann am Ende nochmal so ein ganz kleines Beispiel,
wann nochmal das jetzt also dann auch irgendwann mein Hades umgesetzt
hatte,
Ist aber sonst inhaltlich, also sagen wir jetzt nichts weiter, was man behalten müsste.
Gut, Ampel, dieses kleine Beispiel hatten wir ja schon,
also es gibt im Prinzip drei Ausgänge, rot,
gelb und grün jeweils für die Leuchten.
Es gibt hier Zustände, rot, rot, gelb,
grün und gelb, das heißt also das,
was man so einfach erstmal so als Ampelphase in so einer typischen Ampel auf der Straße,
also irgendwie durchläuft.
Es gibt erstmal in dem Sinne jetzt also keinen Eingang,
sondern es sollen einfach immer nur der Reihe nach Also jetzt
noch unabhängig von irgendwelchen Zeitbedingungen, diese Zustände durchlaufen werden.
Und ja, wie würde man das machen? Fängt eben an mit dem Zustandsdiagramm,
kodiert das Ganze, stellt dann eben die entsprechenden Flusstafeln und Ausgangstafeln aus,
würde die Schaltennetze minimieren und kann das Ganze dann eben letztendlich dann also irgendwo in Hades eingeben. So,
erste Variante, das,
was also auch schon mal am Mittwoch kurz vorgestellt wurde,
also ich habe einfach die Zustände direkt durchnummeriert und zwei BitVector hätte dann eben jeweils hier meinen aktuellen Zustand,
dann eben hier den jeweiligen Folgezustand und eben abhängig von dem Zustand dann eben auch die Belegung der Ausgänge,
also wie man in dem Fall dann eben auch sieht,
ist das Ganze hier jetzt also ein Moor-Automat,
nicht weil also die Ausgangsbelegung hängt dann eben jetzt immer jeweils hier nur von diesem Zustand ab.
Wenn ich dann eben versuche, daraus jetzt mit Pulshalge bauen,
Minimierung jetzt irgendwelche Schaltnetze draus zu machen,
also in diesem Fall kann man das also relativ einfach ablesen,
ich kann man eben sagen, Z1 plus,
also für den Folgezustand wäre dann eben Z1,
XOZ0. Z0 plus wäre dann eben einfach Z0. Nicht.
Das heißt, die wechseln einfach immer nur direkt von 0 nach 1 durch.
Und für die Ausgänge gilt, rot ist eben Z1 nicht,
gelb wäre Z0 und grün wäre Z1 und Z0 nicht.
Gut, das Ganze in Hardes eingegeben, wäre dann also letztendlich
genau diese Schaltung. Und wenn man das dann entsprechend Hier
einmal simuliert. Welche Starre in meinem Anfangszustand rot,
gehe dann eben nach rot, gelb,
mit dem nächsten Tag flanke, habe ich es dann grün,
gelb, rot und so weiter und so fort.
Nicht gut, das heißt,
das Ganze verhält sich dann eben letztendlich so wie von
dem Automaten dann eben auch passend gefordert
Gut, das wäre jetzt die eine Möglichkeit, direkte Realisierung,
wie man sieht, ist also auch nicht sonderlich kompliziert,
man kommt hier mit zwei Flipflops für die Kodierung der Zustände
und eben hier ein paar einfachen Gattern aus.
Trotzdem, man könnte eben auch andere Kodierungen nehmen,
also hier als ein Beispiel, etwas,
wo also letztendlich die Zustandsbit genau den Lampen entsprechen, das heißt,
Demzufolge brauche ich hier jetzt also auch gar keinen Ausgangsschaltnetz mehr,
weil die Ausgangsfunktion da nämlich minimal ist.
Das heißt also, jeweils bei einem Zustand,
das heißt, wenn ich in einem Zustand rot bin,
ist eben dieses Bit Z0 an,
was nämlich direkt quasi dann der Ausgang der roten Lampe ist.
Nicht die beiden sind aus, bei rot, gelb sind die beiden an,
bei grün ist das an, bei gelb ist das an.
Gut, zusätzlich ist hier jetzt also noch sowas wie so
ein Reset mit rein definiert, wo man sagen kann,
okay, gehen erst mal alle Lampen aus und nach dem Einschalten.
Das heißt, wenn ich das Reset-Signal weg ist,
lande ich dann eben erst mit meiner roten Ampel und dann läuft das Ganze eben entsprechend durch.
Gut, wie man hier sieht, Vorteil, Ausgangsfunktion wird minimal.
Nachteil, ich brauche natürlich für die Zustandskudierung jetzt ein drittes Bit.
Das heißt, in der Hardware habe ich dann eben drittes Flip-Flop,
welchen die Zustandsübergänge sind dann also hier teilweise ein bisschen komplizierter.
Also das heißt, dieses hier wäre jetzt die Stelta-Schaltnetz und
das Ausgabeschaltennetz oder Lamderschaltennetz ist in dem Verletzt trivial war.
Also die lahmten jetzt eben wirklich in meinem Hirn
nur direkt an den Ausgängen der entsprechenden Register sitzen.
Dritte Variante wäre dann sowas wie so eine One-Hot-Codierung, dadurch,
dass ich hier einfach immer nur eine feste Folge durchlaufe.
Kann ich jetzt eben sagen, okay, also ich kodiere das
meine Zustände jetzt eben mit Vierbit für die vier Zustände.
Es ist immer nur eine einzelne eins gesetzt.
In der Folgezustand ist da dann eben immer nichts anderes,
als dass man sagen kann,
okay, also die eins so rum gesehen,
waren da dann eben immer allen weiter nach links
und wurde am Ende dann hier einmal zyklisch zurückgeschoben
In dem Fall ist dann die Übergangsfunktion minimal,
weil das Ganze ist dann eigentlich nichts anderes als so ein Register,
was immer nur einen weiter durchschiebt am Ende, quasi in sich selbst zurückgekoppelt ist.
Und auch die Ausgangsfunktion ist hier also auch vergleichsweise einfach hier über zwei oder Gatter,
nicht in Hades, wird das Ganze dann eben letztendlich so aussehen.
Gut, also das nur als ein Beispiel oder eine Veranschaulichung,
dass man eben sagen kann, okay, kann durchaus Sinn machen,
je nachdem, ob man jetzt Delta oder Lamda noch irgendwie kleiner machen möchte,
dann eben auch mit anderen Zustandskodierungen als jetzt mit so einem Binär durchgezählten Modell zu arbeiten.
Letztendlich ist es aber eben wirklich immer davon abhängig,
wie aufwendig soll das Ganze sein, was sind letztendlich meine Kriterien,
möchte ich es möglichst klein haben, möchte es möglichst schnell getaktet haben,
also auch da muss man sagen,
ist sowas hier natürlich, also dann eigentlich optimal,
weil ich dann wenn wir jetzt das wieder an diese Zeitbedingungen zurückdenken,
also mit diesem Setup- und Toolzeiten,
hier dann eben das Ganze maximal schnell machen kann.
Also je nachdem gibt es dann eben unterschiedliche Optimierungskriterien,
die man da einsetzen kann. Gut, anschließend,
jetzt hier auch noch mal kurz beschrieben, Zählschaltung oder Zähler.
Auch da kann man sagen,
also im Prinzip sowas wie ein Zähler ist formal gesehen
ein ähnlicher Automat
Ein trivialer, endlicher Automat, nicht? Also ich habe hier einfach meinen Zustand,
also bei zwei Bit, 0-0, 0-1,
1-0, 1-1 und laufe die eben einfach immer zyklisch durch.
Das Ganze ist in dem Fall hier jetzt also auch nicht von irgendwelchen Eingangsvektoren abhängig,
nicht, sondern mit jedem Takt zähle ich eben entsprechend ein weiter. Gut,
dann kann man sich jetzt natürlich auch noch überlegen,
okay, ich habe noch sowas wie irgendwelche Enable-Leitungen, nicht,
das heißt also nur, wenn das Enable gleich eins ist,
soll weitergezählt werden, ansonsten bleibt der Zähler in dem Zustand,
also dass wir dafür dann eben das entsprechende Zustandsdiagramm dann kann man noch sagen,
okay, also der Zähler soll es vorwärts oder rückwärts zählen.
Gut, hier ist es immer schon mal zum Beispiel Hannes 3-Bezählers nicht,
wo man dann eben sagen kann,
bei Enabled gleich null, bleibe ich in einem Zustand,
wenn Enable gleich eins ist und vorwärts durchlaufe ich das Ganze in dieser Richtung,
wenn Enable gleich eins ist und nicht vorwärts, würde ich eben hier über diese Kanten entsprechend rückwärts zählen.
Also hier ist das Ganze dann immer ja auch nochmal mit
den entsprechenden Tabellen dann aufgezeichnet und nicht, aber gut,
das ist eigentlich selbsterklärend, beziehungsweise trivial, was das macht.
Und gut, das lässt sich jetzt eben beliebig weit treiben.
Also hier wäre das jetzt für ein Fünf-Betzähler,
das heißt also hier jetzt irgendwie mit 32 Zuständen nicht.
Und da gibt es dann eben sowas wie Vorwärtszielen, Rückwärtszielen,
ein Label, Reset, Reset würde dann eben heißen,
von jedem Zustand gibt es dann eben noch eine Karte,
die dann eben auf Null geht.
Ja. Gut, Auch bei CLAN kann man,
wenn man jetzt also im Prinzip diese Diagrama hat,
was natürlich dann also direkt in irgendwelche Schaltungen oder Schaltelemente umsetzen.
Nicht also auch da folgen jetzt hier so auf den nächsten Folien noch irgendwie einige kleine Beispiele.
Wie gesagt, kann man sich dann letztendlich alles selber überlegen.
Deswegen werde ich das jetzt also hier nicht langwierig also irgendwie vorstellen.
Also hier wäre das jetzt also ein Vierbit. Binärzähler mit JK-Flip-Flops,
wo ich dann immer sagen kann, okay,
das unterste Bit, wenn ich durchzähle, Torget in jedem Tag,
kriege ich eine New York Car-Philip-Frogramme vergleichsweise einfach hin,
dass J und K beide gleich eins sind.
Das ist nämlich genau dieses, nicht in der nächst höheren Stufe,
würde das jetzt eben quasi toggeln,
wenn das niederwärtigste Bittleich eins ist und noch eine Stufe höher würde es eben toggeln,
wenn alle beiden niederwärtigen Bittleich eins sind, nicht.
Das heißt, dass letztendlich das,
was dann hier als Logik immer passiert,
ist dann immer jeweils eine Unverknüpfung über alle niederwärtigeren Bitts.
Und wenn all die gleich eins gezählt haben, würde das dann eben entsprechend umschalten.
Gut, auch das kann man dann mit Hades simulieren.
Hier ist das Ganze jetzt also nochmal mit D-Fliffrops gemacht.
Auch da letztendlich Die gleichen Funktionen dahinter, nicht also ein
Dateneingang ergibt sich dann eben immer aus Carrie und dem entsprechend niederwärtigsten Bit.
Und wenn ich dann eben in höheren Witz bin,
dann eben auch wieder die Unverknüpfung,
dass alle Bits gesetzt sind und ein Carry en,
dann würde dann eben der Dateneingang eben entsprechend torgeln
Gut, neben diesen Arten von Zählern, was jetzt also
sogenannte Synchrone-Zähler sind. Sprich, hier habe ich,
wie ich das eigentlich jetzt also auch vorher immer bei dem Entwurf von den endlichen Automaten gemacht habe,
einen Takt oder eine Taktleitung,
die letztendlich, also in diesem Fall, diese Taktleitung,
die dann eben letztendlich parallel an alle Register gleichzeitig geht.
Nicht deswegen beim Zähler, dann eben,
also nehmen wir den hier, auch synchronerzähler,
war ich eben auch hier einen Takt habe,
der jetzt also an alle Flipflops gleichzeitig geht und wenn der Tag kommt,
auch alle Flipflops gleichzeitig umschalten.
Deutlich kleinere Zähler kriegt man in Form von Asynchronzählern,
und zwar ist dort einfach die Idee, dass ich sage,
okay, ich habe hier mal einen Flipflop,
was quasi in der niedrigsten Stufe mit jedem Tag von null nach eins wechselt.
Das heißt also, der Dateneingang ist dann einfach einmal,
der jeweils negierte Datenausgang. Das heißt, das,
was ich damit mache, ist,
dass dieses Flip-Drop mit jedem Tag hin und her schadet und
ich erzeuge mir quasi hier am Ausgang letztendlich einen Tag,
der Eingangstag durch zwei ist.
So, und das, was man dann eben macht,
ist, dass man sagt, okay,
ich nehme jetzt diesen halb so schnellen Takt und das ist dann
also mein Takt für Die nächst höhere Stufe und so weiter und so fort.
Das heißt also mit jedem Flipflop halbiert sich,
also demzufolge dann die Taktdrate, die da rauskommt.
Ich brauche hier also keinerlei Logik, um irgendwie jetzt was
zu machen. Ich kann dadurch dann eben Taktteiler generieren,
wo ich dann sage, halber Takt habe ich an dieser Stelle,
Vierteltakt habe ich an dieser Stelle, Achteltakt an dieser Stelle,
256. Tag dann eben in diesem Fall,
also hier nach dem achten Flipflop
Was hier aber dann im Unterschied zu Synchronzählern wichtig ist.
Deswegen heißt es, Asynchronerzähler, die schalten dann eben auch entsprechende Reihe nach.
Nicht dadurch, dass der Tag, wenn er wechselt, dann erst hier drauf wirkt.
Nicht, wenn der Tag sich ändert, das Ganze dann hier drauf. Das heißt,
wenn diese Flip-Flops jetzt eben entsprechende Verzögerungszeiten haben,
das war das, was ich ja bei den Zeitbedingungen am Mittwoch,
also auch immer vorgestellt habe, wo ich eben gesagt habe,
okay, der Tag Vorderflanke dauert, das eben noch eine bestimmte Zeit,
bis sich der Ausgang ändert, führt das dazu,
dass wenn ich jetzt diese Ausgänge hier also wirklich als so ein Zählvektor nehme,
dann eben diese Bits der Reihe nach auch erst wechseln und nicht alle gleichzeitig synchron,
wie das dann beim Synchronen-Flip-Flop der Fall wäre.
Ich weiß jetzt gar nicht, wie da jetzt,
also das hatte ich vorhin, glaube ich, nicht ausprobiert, die Voreinstellung
Er hat dem... Also das wäre jetzt hier also im Prinzip dann so ein Asynchronerzähler,
also hier habe ich jetzt meinen Takt,
nicht der Ausgang von dem bildet dann eben den Takt für den nächsten und so weiter und so fort. Das Ganze ist jetzt hier eben so gemacht,
dass also in dem Fall,
in dem Modell von dem Flip-Flop eben die Verzögerungszeit relativ groß ist und das,
was man da dann Sieht ist, dass wenn ich jetzt,
also hier raufzähle und jetzt eben mehrere Bits kippen,
also beispielsweise, wenn jetzt der nächste Tag kommt,
würden die alle drei ausgehen, der hier angehen,
also ich ziehe dann von sieben nach acht, dadurch,
dass es aber zeitlich mit einer Verzögerung hier passiert,
würde man hier am Ausgang dann eben noch beliebig viele unsinnige Werte sehen,
was also jetzt in dem Fall dann eben auch sehr schön
in der Hadesimulation sichtbar war
Ich, also das ist dann eben wieder ein Nachteil bei solchen Asynchronen-Zielschaltung. Gut,
also hier nochmal genau das Gleiche,
was ich gerade eben gezeigt hatte, nicht,
also als Vorwärtszähler beziehungsweise als Rückwärtszählern, je nachdem,
also ob ich den Taktausgang oder den Negiertentaktausgang dann jeweils nehme,
habe ich dann eben entsprechend dieses unterschiedliche Verhalten.
Gut, hier dann auch nochmal so aus dieser 74er-Serie dann also irgendwelche Bausteine,
die es da mal gab, wo dann eben auch mit solchen JK-Flip-Flops,
also dann schon irgendwelche Sachen so vorverdrahtet waren,
dass dann damit dann eben solche Fehler aufbauen konnte.
Da gab es dann eben unterschiedlichste Varianten,
wo man dann also Tag durch zwei teilen kann oder durch sechs und dann konnte man das kaskadieren,
dann habe ich das durch zwölf geteilt.
Gut, also kann man also unterschiedliche Beispiele mit aufbauen, interessiert aber Sam Herr Sons jetzt hier, Ihr nagellich, danach gehe ich nicht weiter. Gut,
wenn man jetzt noch etwas kompliziertere Schaltungen braucht, also das,
was er eben in dem Zustandsübergangsdiagramm auch schon so angezeichnet war,
also irgendwie sowas mit vorwärts und rückwärts zählen nicht,
also auch das kann man teilweise beispielsweise dann eben von Verwendung von solchen JK-Flip-Flops relativ elegant lösen,
dass ich dann eben sage,
ich habe eigentlich beide Funktionalitäten und kann das dann eben entsprechend immer umschalten,
nicht letztendlich ist, ergibt sich das,
wenn man das jetzt also in den Tabellen auswerten würde und dann eben entsprechend die Bulschen-Funktion dazu auswert,
dann eben auch so, dass man dann das entsprechend so aufbauen kann, dass sich dann eben letztendlich, also hier beide Realisierungsformen für rauf oder runterzählen letztendlich direkt so umsetzen kann.
Ein anderes Beispiel, was eigentlich dann also noch durch einen anderen Automaten motiviert ist,
der dann also auch gleich noch kommen wird,
ist dann sowas, wo man sagen kann, okay,
also ich möchte jetzt, also hier mein Digitalwecker aufbauen,
mache jetzt also im Prinzip Folgendes,
dass ich hier also im Prinzip so einen BCD-Zähler habe,
BCD, nochmal zurück, Barn Recorded Desimil,
das heißt also irgendwas, wo ich von 0 bis 9 zähle,
nach der 9 kommt dann halt wieder die Null,
und wenn ich das jetzt also hier irgendwie dann noch so wie Jan gedeutet,
also irgendwie kaskadiere und noch mit ein bisschen zusätzlicher Logik so versehe,
dass ich quasi dieses Rücksetzsignal, was also hier wirksam wird,
zum Beispiel an dieser Stelle genau dann mache,
wenn ich also hier eine sechs kodiert habe,
kann ich dafür sorgen,
dass dieses hier hinten quasi nichts anderes ist als ein Zähler,
der von 0 bis 59 zählt und nach 59 bzw. wenn er eigentlich eine 60 machen würde,
setzte er sich hier wieder zurück und ich habe dann wieder 0-0.
Damit kann man da sowas wie so eine Uhr,
beziehungsweise in dem Fall wären das jetzt hier die Sekunden.
Hier hätte ich dann die Stunden realisiert und hier oben ist
das Ganze dann eben so auskodiert,
dass da so irgendwie nach 23 dann eben wieder auf Null gehen würde.
Also auch das kann man dann so entsprechend aufbauen,
beziehungsweise dann eben sich hier das passende Beispiel,
also aus dem Hardess,
also einmal reinladen,
laufen lassen wird,
dann eben auch entsprechend sehen
Dass das Tal dann eben so entsprechend zählt. In dem Fall,
muss man jetzt sagen, also das ist dann eigentlich Teil
einer noch etwas größeren Schaltung, was dann, ah,
sagt man ja immer so ein bisschen so mit das Komplexeste an Beispiel ist,
was wir jetzt also für einige kleine Lehrveranstaltungen einsetzen.
Und zwar geht das da darum,
also im Prinzip so was wie so ein Wecker aufzubauen,
der dann aber eben noch zusätzlich mit dem Funksignal irgendwie gesteuert wird.
Das ist im Prinzip so ein Langwellensignal, wo im Prinzip die genaue Zeitinformation dann eben auch mit reinkodiert ist. Und formal gesehen ist dann eben dieser Wecker,
also nichts anderes, als dass man sagt, okay,
ich habe also zum einen einen vergleichsweise etwas aufwendigeren, endlichen Automaten,
mit dem ich dann also quasi jetzt aus diesem gesendeten Informationen meine Zeitinformation rauskodiere,
wenn ich die richtig empfangen habe,
soll da eben intern das Uhrwerk stellen,
wenn ich sie nicht richtig empfangen habe,
möchte ich das Uhrwerk noch irgendwie von Hand stellen können oder möchte ich eben irgendwie jetzt sagen,
okay, also es ist eine Zeit und der soll einfach stumpf Weiterzählen,
ohne dass jetzt gerade ein Radioempfang hat.
Und dann möchte man vielleicht noch irgendwelche Wegzeiten einstellen können und, und, und.
Letztendlich funktional gesehen ist das Ganze dann eigentlich eine Schaltung,
die sich im Prinzip dann als eine Menge gekoppelter Automaten,
also sprich verschiedene Zähler, Dekodierautomaten für dieses Zeitsignal,
irgendwelche Automaten, mit denen ich dann also letztendlich irgendwie Benutzereingaben,
also sprich irgendwelche Tastendrücke, Abfrage und sage,
okay, wenn ich das und das gedrückt habe,
dann bin ich in dem Zustand,
wo ich jetzt also irgendwie die Zeit stellen kann.
Und wenn dann die Taste gedrückt wird, dann soll das und das passieren.
Und so war es, soll dann entworfen werden und das ist im Prinzip,
wenn also Teil sind es, Praktikum ist, wo es dann also im Prinzip um Hardwareentwurf geht.
Ich also hier auch nur mal aufgezeichnet,
also wie jetzt im Prinzip so die Grundidee ist,
jetzt von diesem Zahlzeichensignal, also das,
was im Prinzip also aus dort gesendet wird,
also aus dem DCF-Sender davon, in der Nähe von Frankfurt,
bei Mainflingen ist das, ist im Prinzip,
also wenn ich das jetzt umsetze und da draußen digitales Signal mache,
sodass ich sage, ich empfange da eins,
irgendwann wechselt dieses Signal nach Null.
Und dann habe ich eben entweder 100 Millisekunden oder 200 Millisekunden lang eben eine Null,
dann geht es auf eins und bleibt dann eben für den Rest der Zeit,
bis ich insgesamt hier als Periode eine Sekunde überbrückt habe,
dann eben eins und dann kommt eben hier das Nächste.
So, das heißt, was man hier macht,
ist, dass man innerhalb einer Sekunde ein einzelnes Bit überträgt.
Ist jetzt natürlich nicht die super Übertragungsrate, genügt aber natürlich,
weil ich ja eigentlich nur wissen möchte,
welches Datum haben wir und in welcher Minute befinde ich mich und die Sekunden zählen dann eigentlich automatisch selber hoch.
Und was dann eigentlich nur interessant ist, ist eben quasi diese Rückflanke,
das ist nämlich der Beginn einer Sekunde und das kriegt man dann also wirklich so innerhalb von Mikrosekunden letztendlich genau hin.
Das heißt also, man hat damit also schon eine relativ genaue Zeitinformation mit diesem Ding.
So, was er jetzt natürlich noch brauche, okay,
ich kann jetzt also in einer Sekunde ein Bit übertragen.
Jetzt muss er natürlich wissen,
weil das dann ja in so eine Art Protokoll stattfindet,
in welcher Sekunde befinde ich mich jetzt gerade,
um zu sagen, okay, das ist also genau dieses Bit,
was mir also irgendwie die Information von den Minuten irgendwie angibt.
Dazu kann man dann eben sagen,
insgesamt wird dann eben in einer Minute nicht sehr 60,
sondern nur 59 Bit übertragen.
In der 59. Sekunde fehlt nämlich quasi dann diese Flanke. Das heißt,
man hat dann eben hier so eine sehr lange Pause und mit
der nächsten Minute mit der Flanke weiß ich dann eben genau,
okay, jetzt starte ich.
Und dann kann man quasi auch mitzielen,
dann eben jetzt jeweils hier für jedes Bit,
an welcher Stelle ich bin, damit dann also dieses Signal an eben auch passend interpretieren.
Gut, also das nur so grob zu der Idee, was dahinter steht.
Also wie gesagt, das wird dann eben irgendwie so komplett aufgebaut.
Hier nur so ein Teilausschnitt davon. Also wie gesagt,
das kann man sich dann eben auch hier in das entsprechend aufrufen,
damit mal irgendwie durchspielen. Nicht,
dann gibt es dazu dann eben auch noch so ein entsprechendes Modell,
was dann also genau das in Verse macht.
Das heißt, man stellt dann eine Zeit ein und entsprechend
diesem Protokoll wird dann eben irgendwie so ein Signal passend irgendwie gewechselt,
dass das dann auch dem entspricht.
Nicht damit kann man das dann eben auch machen.
Gut, hier dann nur Ausschnitte aus der Schaltung.
Ich denke mir, das ist jetzt also hier nicht weiter interessant.
Eine andere Sache, was dort dann auch noch so mit drin ist,
weil wir das dann also ganz früher auch mal wirklich so
als kleinen Chip selber gemacht und umgesetzt haben
Ich möchte hier jetzt also irgendwelche Anzeigen ansteuern.
Also dazu dann auch nur als Trick. Gut,
sieben Segmentanzeige, davon sechs Stück, kann ich sagen,
ich bräuchte eigentlich jetzt für jedes Segment eine Leitung,
um zu sagen, geh an oder geh aus.
Das heißt, sieben Leitungen pro Anzeige, wenn ich jetzt sagen möchte,
okay, ich habe also Stunden, Minuten, Sekunden,
brauche ich sechs Stellen, bräuchte ich also demzufolge dann 56 Leitungen.
Wenn ich jetzt irgendwie so einen kleinen Ship mit wenig Ein-
und Ausgängen habe, ist das irgendwie nicht so ganz praktikabel.
Deswegen wird dann also hier auch noch irgendwie so ein Trick angewendet,
dass man im Prinzip die Ausgabe dann eben in so einem Zeitmultiplex macht,
dass man nämlich nur sagt, okay, ich mache nichts anderes,
als dass ich nur die Leitung für eine Stelle rausführe,
sieben Stück.
Und dann habe ich nur noch irgendwie sechs Auswahlleitungen,
mit denen ich sage,
welcher von denen jetzt
gerade aktiv ist
Und das, was man dann eben machen kann,
ist, dass man sagt, okay,
wenn ich das Ganze nur schnell genug der Reihe nach durchlaufen lasse,
das heißt, er ist die niedrigste Stelle von den Sekunden,
dann die nächste von den Sekunden und so weiter.
Und das Ganze jetzt, also was weiß ich,
mit irgendwie 300 Herz betreibe, dann ist das menschliche Auge so träge,
dass es also eigentlich alles gleichzeitig leuchtend sieht, während,
wenn man das also zum Beispiel jetzt mit der Digitalkamera aufnimmt,
würde man dann eben auch feststellen,
es ist immer nur wirklich ein einzelnes Segment an.
Das sind dann eben auch noch irgendwie so Tricksereien,
die man da also machen kann,
um beispielsweise dann also die Anzahl von irgendwelchen
Leitung zu minimieren in der Hardware. Gut, also auch
dazu gibt es dann also irgendwie so ein passendes Hades Beispiel.
Also da sieht man dann mich also letztendlich,
also dann auch nur so ein bisschen visualisiert, diesen Effekt.
Nee, habe ich jetzt nicht mehr
50 Display ist okay. Wenn ich da sieht beieinander,
also hier letztendlich auch nur irgendwie so diesen Effekt,
dass dann immer jeweils nur eine von denen irgendwie aktiv ist
und das dann halt von der Reihe nach durchschaltet.
Gut, das ist jetzt hier natürlich,
also in der Simulation ist ein bisschen munteres Rumgeblinken nicht,
aber wenn man das also wirklich in Hardware aufbaut,
dann sieht man ihm eigentlich auch sehr schön,
dass dann also Alles gleichzeitig an ist, nicht,
aber dahinter verbirgt sich dann eben letztendlich genau dieser Trick.
Gut, ja, das eigentlich jetzt abschließend nochmal so zu dem Themen,
okay, was sind jetzt also vielleicht so die komplexeren oder Beispiele für etwas komplexere, ähnliche Automaten.
Jetzt abschließend hier nochmal einige Folien, wo es also darum geht,
wie sieht das mit Asynchronschaltung aus?
Weil angefangen haben wir ja also in diesem Kapitel im Prinzip im Prinzip,
dass wir gesagt haben, okay, Schaltwerk ist irgendwie Schaltnetz mit Rückkopplung.
Und diese Rückkopplung passiert einfach jetzt aufgrund der Garterverzögerungszeit irgendwie asynchron.
Im Prinzip muss man jetzt eben sagen,
dass die Idee auf irgendwie so einen zentralen Tag zu verzichten einige Vorteile hat,
weil es also Schaltung schneller machen kann. Nachteil bei dem Ganzen ist immer,
was sie ja so auch ganz am Anfang immer schon gesagt hatte,
asynchronische Schaltung, dadurch, dass ich eben Sowas wie instabile Zustände habe,
wo eben das Schaltwerk dann also irgendwie durchläuft oder vielleicht oszillieren kann,
sind, erstmal sehr schwer zu entwerfen, nicht nur nichts,
das ist eigentlich auch der Grund dafür,
weswegen man in der Regel in der Hardware nur irgendwie wirklich jetzt bei größeren Schaltungen eben immer nur synchrone Schaltungen hat.
Das heißt, also ich habe jetzt wirklich nur sowas wie
flankengesteuerte Flipflops in den Rückkopplungsfaden und dann eben entsprechend meine Schaltnetze
und kann das Ganze dann eben irgendwie synchron laufen lassen
Einziges wirklich größeres Beispiel, was mir bekannt ist. Es gab also mal von einem Armprozesse,
wo man dann wirklich sagen kann, also ein kompletter kleiner Prozessorkern,
mal eine Variante, die also asynchron gelaufen ist,
zumindest also mit der damaligen Technologie und der derzeitigen Zeit,
auch vergleichsweise schneller und energieeffizienter war, als die synchronen Schaltungen,
nicht bloß das ist da dann eben,
muss man jetzt eben auch nur sagen,
als Beispiel für diese Technik dann eben auch was,
was nice, also nicht beliebig so skalieren kann und sagen kann,
ja gut, also nicht,
wenn ich dann da so irgendwie so Mitte der 90er Jahre mal irgendwie sowas hatte,
nicht, also heute ist die Technik,
also nochmal irgendwie um Faktor 10 kleiner und die Prozessoren irgendwie um Faktor 200 schneller,
wenn ich das jetzt also irgendwie noch asynchron machen würde,
nicht, dann wäre das doch eigentlich toll und hervorragend,
nicht bloß da muss dann eben sagen,
dass das also wirklich dann vom Entwurf her so schwierig ist oder zu handhaben ist,
dass sich da also dann auch irgendwie nie jemand war da dran gewagt hat,
weil also das, was dann dort an Protokollen ist,
also dann entsprechend schwierig ist.
Grundidee bei dem Ganzen ist, wenn man jetzt sagt,
okay, ich nehme jetzt sowas wie so einen kleinen Mikroprozess oder Mikrocontroller.
Generell muss man sagen, also angenommen, ich würde jetzt
der Reihe nach mehrere Operationen ausführen. Addition, Multiplikation,
Inkrement, lese irgendwas aus dem Speicher oder mache nichts,
dass diese Operation letztendlich irgendwie alle unterschiedlich lange dauern,
je nachdem, was in dem Schaltnetz,
was da eigentlich für die Operation verantwortlich ist
Passiert. Das, was man als Taktfrequenz hat,
richtet sich, aber letztendlich nach der längsten Zeit. Das heißt,
wenn ich jetzt eben sage, okay, ich habe hier,
also bei der Multiplikation eben eine vergleichsweise lange Berechnungszeit,
dann wird eben die Taktfrequenz,
auch wenn viele andere Operationen kürzer und oder vielleicht sogar deutlich kürzer sind,
dadurch bestimmt, dass ich sage,
okay,
hier für die Multiplikation brauche ich eben entsprechend lange nicht und
zusätzlich brauche ich also hier für die Register noch irgendwelche Setup-Zeiten
und das bestimmt mir dann eben meine maximale Taktfrequenz der Schaltung
So, wenn man das jetzt schafft zu sagen,
okay, ich habe keinen Tag,
sondern die einzelnen Teile signalisieren jetzt durch irgendeine Art von Protokoll,
okay, ich habe ein Ergebnis und das nächste Teil kann jetzt mit diesem Ergebnis weiterrechnen.
Und auf der anderen Seite kann ich dafür jetzt, wenn das abgenommen wurde,
dann eben auch an meinem Eingang also wieder irgendwelche neuen Werte einlesen und damit was Neues machen.
Wenn man das jetzt also schafft, irgendwie in irgendein Protokoll zu gießen,
kann man dann eben sagen, okay,
also ich kann das Ganze eben dadurch deutlich schneller machen,
dass ich hier dann zwar vielleicht irgendwelchen zusätzliche Zeit brauche,
um jetzt also dieses Protokoll irgendwie abzuarbeiten,
aber insgesamt das Ganze dann natürlich dann also wirklich überwiegend durch diese Verzögerungszeiten in den jeweiligen Schaltennetzen dann nur noch bedingt wird.
Da kann man sich jetzt also unterschiedliche Varianten ausdenken,
also da zwischen den einzelnen Teilkomponenten nicht. Also man kann sagen,
ich habe hier also irgendwie so einen Datenbus,
der von A nach B geht und es gibt dann eben irgendwie sowas wie so ein Request-Signal,
was dann eben sagt, okay, ich habe hier neue Werte,
verarbeite die bitte, nicht nur wenn dieser Teil,
also mit da anfängt jetzt also irgendwie was mit zu machen.
Und das quasi abgenommen hat. Das heißt,
dieser Teil jetzt eben hier mit neuen Werten weiterrechnen könnte,
gibt es dann eben so ein Acnoledge zurück.
Das kann man eben quasi jetzt abhängig von der Bedingung machen,
dass das Request quasi auf eins geht, wenn neue Daten da sind.
Nicht dieser Teil, wenn er das abnimmt,
quasi dann mit dem Acnoledge gleich eins sagt, okay,
ich fange jetzt an mit deinen Daten zu arbeiten
Nicht daraufhin, kann der dann eben hier dieses Request zurücknehmen.
Irgendwann, wenn der hier mit der Verarbeitung fertig ist,
geht das A Knowledge auf null. Und dieser Tal kann dann
eben entsprechend hier neue Daten anlegen und das Ganze geht wieder von vorne los.
Man kann das noch ein bisschen vereinfachen,
indem wir das jetzt also nicht pegelabhängig,
wo ich also quasi immer hier diese Eins aktiv habe,
sondern wo ich dann sage, ich gehe jetzt,
dass ich hier nur auf die Tag flanken.
Das heißt, jedes Mal,
wenn sich hier also der Wert ändert,
ist das eine Request, wenn der sich hier ändert,
habe ich mein A Knowledge und so weiter
Ne, man kann das dann eben auch noch irgendwie machen,
dass man sagt, na gut, also statt,
Request und McKnowledge habe ich also hier die Daten einmal in normaler Eimer ein invertierter Form,
wenn beide stabil da liegen,
habe ich gültige Daten und kann damit arbeiten,
wenn die unlike sind, dann passiert hier quasi gerade noch die Berechnung.
Also auch da gibt es dann also sehr viele
sehr unterschiedliche Varianten, die man sich da ausdenken kann.
So, und ein Element, was man da dann eben
nehmen kann,
ist die sogenannte Malla Segate
Was im Prinzip dann also auch ist, so eine Schaltung, wo ich also jetzt hier Eingänge habe.
Ein Ausgang und eben eine Rückkopplung dieses Ausgangs auf die Eingänge als Funktion würde ich dann eben im KV-Diagramm,
also im Prinzip hier diese drei Schleifen haben und die Funktionalität von dem Ganzen ist,
letztendlich so, dass man sagt,
wenn beide Eingänge den gleichen Wert haben,
dann wechselt der Zustand von diesem Mala See-Gate auf genau diesen Wert.
Wenn anschließend dann eben nur einer von diesen Eingängen sich ändert,
aber dann eben noch nicht den entgegengesetzten Wert hat,
dann wird dieser Zustand beibehalten.
Also das würde man dann eben auch entsprechend in der Simulation
passend sehen
Nicht, also wenn ich jetzt hier beide auf eins setze,
habe ich im Ausgang eine Eins,
wenn jetzt irgendwie einer von denen nur auf Null geht,
ändert sich, nee, also beide auf Null,
am Ausgang Null,
wenn jetzt nur einer von denen dann also irgendwie auf eins geht,
ändert sich nichts.
Wir haben beide auf eins sind, ändert sich dann eben auch der Ausgang.
Und auch da habe ich dann eben quasi dieses historiese Verhalten,
dass ich hier dann erst mal nichts ändert,
es seien beide, haben dann wieder den gleichen Wert.
Und damit hat man dann im Prinzip dann eben
auch so ein speichernes Verhalten mit dieser Rückkopplung dort dann,
also letztendlich mit drin
Gut, und dieses Element kann man dann eben nehmen,
um beispielsweise dann eben irgendwelche einfachen Schaltungen zu betreiben.
Also man kann das auch noch erweitern auf drei oder mehr Eingänge.
Und damit kann man dann im Prinzip sowas wie so eine Art kleine Pipeline aufbauen.
Grundidee ist im Prinzip folgende, dass sich also anstattet zu sagen,
ich habe jetzt hier also irgendwie sowas wie so ein Zwei-Phasen-Takt,
schreibe hier irgendwelche Werte rein und kann jetzt hier quasi einzelne Werte speichern und dynamisch in diese Pipeline einfüllen.
Das heißt, wenn die leer ist und dort noch nichts drin ist,
würde der erste Wert eben direkt hier bis zum Ende durchrutschen.
Der nächste wird dann bis hier, der nächste dann bis hier,
sodass man die dann eben der Reihe nach füllen kann,
in die ich dann also im Prinzip so ein FIFO-Verhalten habe,
aber jetzt eben nicht eine bestimmte Anzahl von Takten brauche,
sondern wenn, je nachdem wie voll oder wie leer die ist,
wird dann eben die jeweils letzte benutzte Stelle genommen.
Und sowas kann man dann Das ist eigentlich jetzt das Letzte,
was hier noch kurz sagen würde,
kann man dann eben auch beispielsweise dann eben entsprechend mit Hades simulieren.
Was dann eben relativ einfach,
also jetzt hier also über diese Malacy Gates zu realisieren ist,
also hier habe ich jetzt quasi eine Pipeline mit,
in der drei Bit gespeichert werden können.
Also wenn ich jetzt,
dass ich hier Write auf eins setze, Ähm,
geht das hier erstmal durch, wenn ich das jetzt wieder zurücknehme,
habe ich hier eben das erste Bit reingeschrieben.
Beim zweiten Mal habe ich dann eben hier das zweite Bit
reingeschrieben, beim dritten Mal das dritte Bit.
Hier gibt es dann eben eine Leitung available, beziehungsweise full.
Und hier mit dem Read kann ich dann eben von der
anderen Seite einzelne Bits dann eben auch wieder rauslesen.
Beziehungsweise kann das dann eben hier dann eher auch entsprechend jeweils
immer voll, beziehungsweise leer machen.
So eine Struktur kann man dann eben beispielsweise benutzen,
um jetzt also solche Handshake-Protokolle zu realisieren
Also die eigentliche Rechenfunktion ist hier ja noch nicht mehr drin,
aber das ist also etwas, wo man sagen kann,
okay, damit kann ich jetzt eben Werte speichern und eben mit so einem Handshake sagen,
okay, also ich, da sind neue Werte, mach was damit.
Und irgendwie die Schaltung, die damit jetzt also quasi weiterarbeitet,
kann dann eben mit dem Read dann eben wieder sagen, okay, also ich nehme jetzt mein Datenwort und fange damit an, eben entsprechend weiterzuarbeiten. Gut,
das nur mal so als ganz kurzer Exkurs zu dem Thema asynchrone Schaltung,
da sind wir jetzt eigentlich also auch mit dem Tal zu den Schaltwerken soweit schon durch,
dann werde ich jetzt also hier nochmal relativ kurz ein bisschen was generell sagen zu dem Thema Rechnerarchitektur,
was verbirgt sich dahinter beziehungsweise was fehlt vielleicht eben auch noch an Komponenten,
die wir brauchen, um jetzt außer Schaltnetzen und Schaltwerken,
dann also irgendwie das Ganze,
da sitzt du irgendwie in einer komplexeren Struktur zusammenzufügen,
dass man dann eben wirklich mal sowas wie so einen ganz kleinen,
einfachen Rechner, also eben so ein klassisches von Neumann-Modell irgendwie zurecht bekommt.
Anschließend werden wir dann, was dann eigentlich, sagen wir mal,
so der, ich sag mal, zweite Teil der Vorlesung ist,
da noch ein bisschen eher in die Richtung der Software gehen,
wo wir jetzt also quasi gesehen haben, was sind also die Grundbestandteile,
die eigentlich so eine Rechnerarchitektur dann eben ausmachen,
wie wir in die zusammengefügt,
das ist also dann eben auch letztendlich der Inhalt des Rechnerstruktur- und Praktikums.
Und an der Schnittstelle wird dann eben letztendlich betrachtet,
okay, wenn ich jetzt also irgendwelche Software habe,
irgendwelche Befehle, ganz unten auf Assembler-Ebene,
wie wird die dann eben auf so einer Hardwarearchitektur abgearbeitet?
Nicht wie werden da die entsprechenden Rechenoperationen bzw. sonstigen Operationen dann eben wirklich ausgeführt?
Wie werden die Daten dargestellt, wo werden sie gespeichert und so weiter und so fort.
Gut, da kommen wir erstmal zu dem Thema,
was fehlt uns jetzt eigentlich noch an so einer Rechnerarchitektur?
Dazu habe ich jetzt also hier nochmal zwei unterschiedliche Aussagen,
Beschreibung, Definition von einigen Wissenschaftlern rausgenommen,
was ist Rechnerarchitektur, nicht in der Kamera,
also zum einen sagen,
also The Term Architecture as used year to discribe the attributed of a system,
as seen by the programmer,
special the conceptual structure and functional behavior,
as disting from the organisation and dataflow and control the logital
and the physical implementation von den Herrn Amdalblauer und Brooks
Ähm... Ja, Mitte der 60er Jahre, damals bei UEM angestellt.
Ähm... Das als eine Definition als zweite Definition,
The Study of Computer Architecture. Ist das Study of the
Organization and Interconnection of Componence of Computer Systems?
Computer Architects, Constructs, Computers von Basic Building Blocks,
Such as Memories, Aerismatic Yuanits and Bassis.
Und dann geht das auf dieser Seite nochmal komplett weiter,
verzichte ich jetzt mal darauf,
das vorzulesen
Was man aber eigentlich bei diesen beiden Architekturen schon sieht oder
bei diesen beiden Beschreibungen schon sieht, also Rechnerarchitektur,
beinhaltet eigentlich irgendwie so zwei Aspekte. Nämlich zum einen,
also die ist, was in der ersten Aussage drin war,
also das funktionale Verhalten oder dieses Prinzip, sprich,
wie sieht die Programmierschnittstelle aus, was ist der eigentliche Befehlssatz,
das, was man im Englischen immer als Instruction-Set-Architecture bezeichnet.
Und wie ist die Maschinenorganisation? Das heißt also,
wie werden Befehle abgearbeitet
Nicht, das ist dann das, was,
also dann im nächsten Kapitel dann als Instruction-Set Architection letztendlich folgen wird.
Nicht, das heißt, da geht es eben wirklich darum zu sagen,
okay, welche Befehle habe ich, addiere zwei Zahlen multipliziere, das lade irgendwas in Register.
Wie mache ich das jetzt auf irgendeiner Hardware-Einheit? Und der zweite Teil,
oder die zweite Definition,
von einem Stone geht dann eben mehr in die Richtung der Hardware-Architektur,
nämlich also wirklich so den strukturellen Aufbau,
das heißt, die Erweiterung von dem,
was wir jetzt hier gerade bei den Schaltwerken gesehen haben,
wo man eben sagt, okay,
ich habe jetzt hier irgendwie meine Blöcke und baue die irgendwie zusammen und verbinde die irgendwie so und so miteinander.
Und auf dieser physikalischen Hardware-Struktur kann ich dann eben genau diese Befehle irgendwie passend abarbeiten.
Das heißt, da geht es dann eben jetzt wirklich mehr um die technische Implementation.
Das heißt, welche Speicher habe ich da,
welche Alus habe ich da, wie sind die miteinander verbunden.
Und das dann natürlich also auf ein bisschen höhere Abstraktionsebene,
als es nur irgendwie einzelne Gatter zu betrachten,
weil habe ich jetzt auch gesagt, okay,
wird einführend hier immer mal in rechner Strukturen gebracht.
Sollte man mal gehört haben, nicht,
aber wenn man letztendlich sich dann also wirklich irgendwo an Hardwareentwurf oder sowas macht,
betrachtet man das eigentlich nicht mehr auf dieser Abstraktionsebene, sondern entsprechend deutlich höher.
Gut, dann werde ich angesichts der Tatsache,
dass er jetzt hier die nächsten Folie noch Wiederholungen sind,
aber das dann doch wieder ein bisschen länger dauert,
als das jetzt irgendwie die letzten drei Minuten Am Freitag nicht überziehen,
sondern sagen,
ein schönes Wochenende und am nächsten Mittwoch kommt dann nochmal kurze
Wiederholung zum Fonneumann-Konzept und dann eben eigentlich zu dem,
was es da dann
noch alles fehlt