Brainstorm INF2 Praktikum [Teilaufgabe 2]

Antworten
Benutzeravatar
cyrusgolden
Beiträge: 34
Registriert: 13.11.2011 16:57
Matrikel: Ich bin doch kein Student.

Brainstorm INF2 Praktikum [Teilaufgabe 2]

Beitrag von cyrusgolden » 05.05.2012 20:20

In Teilaufgabe 2 des Informatikpraktikums ist eine ziemlich harte Nuss zu knacken: Die Realisierung einer zeitlich korrekt ablaufenden Simulation, die zudem auch Rückkopplungen erlaubt.

Da Programmierstil und -konzept sehr individuell ausgeprägt sind, ist es wohl sinnvoller wenn wir uns, statt über konkretem Java-Code zu brüten, gemeinsam Gedanken darüber machen, was die Aufgabenstellung überhaupt fordert und wie man das am besten realisieren kann.

Eine Idee

Grundsätzlich nehme ich mal an, dass ein Gatter nicht mehr, wie noch in der ersten Aufgabe, sein Ausgangssignal selbst ändert, sondern ggf. ein Event erzeugt, das sich seinerseits in die Liste einträgt, um später wieder aufgerufen zu werden und dann nach entsprechender Wartezeit eine Änderung am betreffenden Signal zu bewirken. Dieses Vorgehen erfordert spätestens beim Eintragen eines Events in die Liste eine Plausibilitätsprüfung, um widersprüchliche und wirkungslose Events abzufangen.
Es müssten dann durch die Ausführung eines Events hervorgerufenen Events zur Laufzeit an der zeitlich korrekten Stelle in die Liste eingetragen werden.

Das Problem

In Teilaufgabe 2 soll ein RS-FlipFlop simuliert werden und im gegebenen Quellcode merkt Chr. Hochberger an: "[...] Diese Initialwerte müssen mindestens einmal durch die Schaltung propagiert werden, bis sich ein stabiler Zustand einstellt. Um das festzustellen gibt es verschiedene Methoden (im Gatter mitzählen, wie oft sich der Wert ändert. Im Signal mitzählen, wie oft es geändert wurde)."

Wozu mitzählen, wie oft eine Änderung erfolgte? Ab welchem Wert würde man denn den Stabilzustand als erreicht ansehen und sollte sich dieser nicht vielmehr von alleine einstellen?
Jetzt konkreter am Code: Wie soll denn bei bloßer Anlegung "vernünftiger Initialwerte" überhaupt im Programm etwas vor sich gehen, wenn die oben beschriebene Idee besagt, dass Änderungen an Signalen nur über Events erfolgen?

kiti
Beiträge: 16
Registriert: 04.12.2010 11:08
Studienrichtung: Elektrotechnik
Matrikel: 2010

Re: Brainstorm INF2 Praktikum [Teilaufgabe 2]

Beitrag von kiti » 06.05.2012 13:24

Du musst übersehen haben, dass irgendwo in den Kommentaren vom Timingsimulator steht, dass die Eventqueue nicht benutzt werden soll während dieser Stabilzustand berechnet wird. Man muss also wo abspeichern, ob der Stabilzustand schon erreicht ist und wenn nicht muss die Berechnung genauso wie in Aufgabe 1 ablaufen.
Und was der sinn von dem Ganzen ist: Du kannst ja ausprobieren das Programm durchlaufen zu lassen ohne den teil mit dem Steadystate, es funktioniert so auch schon nur am Anfang kommen falsche Ergebnisse zu falschen Zeiten raus, weil in den rückgekoppelten Signalen eben noch überall 0en drin sind.

Benutzeravatar
cyrusgolden
Beiträge: 34
Registriert: 13.11.2011 16:57
Matrikel: Ich bin doch kein Student.

Re: Brainstorm INF2 Praktikum [Teilaufgabe 2]

Beitrag von cyrusgolden » 10.05.2012 15:32

Weil es mir keine Ruhe ließ, habe mir eben angeschaut, wie "Nils-Team" vor einigen Jahren die Aufgabe gelöst hat. Die Dateien sind hier ja verfügbar.

Waren die Jungs eine Ausnahme oder habe ich mit dem Versuch, eine Echtzeitsimulation zu schreiben mit Kanonen auf Spatzen geschossen?

gruenemoehre
Beiträge: 7
Registriert: 05.10.2011 10:17
Matrikel: 2011
Angestrebter Abschluss: Dipl-Ing.

Re: Brainstorm INF2 Praktikum [Teilaufgabe 2]

Beitrag von gruenemoehre » 11.05.2012 05:43

ich glaube, dass du da eher die Ausnahme darstellst... nicht böse gemeint ;)

Benutzeravatar
Farsotstider
Beiträge: 18
Registriert: 19.05.2008 11:49
Geschlecht: männlich
Studienrichtung: Elektrotechnik
Matrikel: 2007

Re: Brainstorm INF2 Praktikum [Teilaufgabe 2]

Beitrag von Farsotstider » 22.05.2012 13:33

Wozu mitzählen, wie oft eine Änderung erfolgte? Ab welchem Wert würde man denn den Stabilzustand als erreicht ansehen und sollte sich dieser nicht vielmehr von alleine einstellen?
Ich hatte es damals glaube ich so 100 Mal durchlaufen lassen und dann gesagt "es muss stabil sein". Eigentlich sollte er sich automatisch einstellen sobald man einmal etwas eingegeben hat, jedoch sollte man bei sehr komplexen Schaltungen (so etwas kommt bei der Verteidigung) doch ein wenig mehr Durchläufe machen, damit der Simulator wirklich alles einmal durchgeschalten hat.
Jetzt konkreter am Code: Wie soll denn bei bloßer Anlegung "vernünftiger Initialwerte" überhaupt im Programm etwas vor sich gehen, wenn die oben beschriebene Idee besagt, dass Änderungen an Signalen nur über Events erfolgen?
Nun, du musst dann da schon ein paar Werte eingeben und dann über so etwas wie die "Weltzeit" Events erzeugen, die dann in der Schaltung umgesetzt werden ;)
Ich hatte das damals glaube ich so gemacht das ich alles in eine Liste geschrieben habe und die Zeit dann über die Eventaufrufe festgelegt habe - nagelt mich daran nicht fest, das ist schon eine Weile her.

Soweit ich mich erinneren kann hatte ich das auch ein wenig zu schwer gemacht, ich hatte erst simuliert & dann die Plausibilitätsprüfung gemacht, andersherum geht es natürlich schneller. Wobei ich das ehrlich gesagt sinnlos empfinde, da moderne Simulationstools das sowieso besser hinbekommen als unser Projekt das ja nur Einblicke in die Java-Programmierung geben soll.

Antworten

Zurück zu „2. Semester: Diskussionen“