2.3.2 Das Interface zum PC "pc_if.vhd"

Die eine der beiden in eine eigene Beschreibung ausgelagerten Funktionseinheiten ist das Interface zum PC in der Datei pc_if.vhd.

Wie aus dem Blockschaltbild des PC-Interface (3.3.2) hervorgeht, umfaßt es folgende Komponenten:

• Verwaltung des Instruktionsregisters i_reg, welches die Befehle des PCs speichert.
• Zwei Automaten, um die Vielzahl der Kommandos vom PC teilparallel auszuführen.
• Verwaltung des Statusregisters, welches erwartete Handshaking-Signale, Laufmodus des Mikroprozessors, aufgetretene Fehler und letztes Konfigurationsergebnis widerspiegelt.
• Ein Multifunktions-Zähler counter, von 0 bis 8 mit Reset.
• Multiplexer, um an den PC wahlweise den Inhalt des Statusregisters oder den gepufferten Wert von Adreß- bzw. Datenbus zu senden.
• 8 Bit-Schieberegister konf_reg mit Funktionen Laden, Schieben und Speichern um Konfigurationsdaten von Byte- auf Bitbreite umzusetzen.
• Zwei mit der Rückflanke betriebene Puffer für die Automatenzustände, um das gegenseitige Abfragen der Automaten sicher zu machen.
• Diverse Logik, die etliche, teilweise über Flipflops gepufferte, Ausgangssignale erzeugt. Diese werden abgeleitet aus Automatenzuständen und Registerinhalten.

Nachfolgend sind obige Punkte in der Reihenfolge ihres erstmaligen Erscheinens in der VHDL-Beschreibung erläutert.

Die diverse Logik

Die Beschreibung findet sich in pc_if.vhd im zwischen den Marken

"--- Diverse Logik Anfang ---" und "--- Diverse Logik Ende ---".

Dieser Abschnitt enthält diverse konkurrente Zuweisungen an Signale, die meistens von den Zuständen der Automaten abhängig sind. Während die Automaten also die für einen Befehl typische Folge von Zuständen durchlaufen, generieren diese Logiken (die -Schaltnetze der Automaten) die Signale, die die eigentlichen Aktionen hervorrufen und die Befehle durch ihre Auswirkungen separieren.

Wegen der Einfachheit der meisten dieser Zuweisungen sei hier nur auf die ausführlichen Kommentare der VHDL-Quelle verwiesen.

Die Puffer für die Automatenzustände: c_state_buffer und c_state2_buffer

Die Beschreibung findet sich in pc_if.vhd im Prozeß ZUSTAENDE_PUFFERN.

Wie man 3.5.1 entnehmen kann, fragen beide Automaten des PC-Interface sich zu bestimmten Zeitpunkten gegenseitig ab. Um Fehler durch sich während der Abfrage ändernde Zustandsbits auszuschließen, werden selbige Bits nicht direkt abgefragt, sondern zwei Puffer, in denen mit der Rückflanke der aktuelle Automatenzustand abgelegt wurde.

Damit kann auch hier die saubere Aufgabentrennung der Taktflanken eingehalten werden: Automaten nähren sich von der Vorderflanke, alle von ihnen abhängigen oder -gefragten speichernden Elemente (hier also status_reg, counter, konf_reg, sstep_pulse_ff, progr_dclk, c_state_buffer, c_state2_buffer, i_reg) agieren mit der Rückflanke; siehe hierzu auch Kap. 2.3.5.2 Taktung der Prozesse - Fehlervermeidung).

Das Instruktionsregister i_reg

Die Beschreibung findet sich in pc_if.vhd im Prozeß IREG.

Die Abarbeitung eines über das PC-Interface gesandten Befehls im Hilfs-FPGA orientiert sich an dem Vorbild existierender CPUs. In einem Wartezustand (hier: wait_for_event) wird auf das Anliegen einer gültigen Instruktion gewartet (hier signalisiert durch m_obf '0'), woraufhin der Automat in einen allgemein fetch genannten Zustand fortschreitet, in welchem er den Wert der Instruktion für die weitere Bearbeitung speichert. Es folgt ein meist decode genannter Zustand, in dem die Instruktion ausgewertet wird, d.h. es wird je nach Befehl zu unterschiedlichen Bearbeitungssträngen verzweigt, die alle wieder zu wait_for_event zurückführen.

Das Instruktionsregister i_reg ist nun dasjenige, welches im Hilfs-FPGA den Wert der aktuellen Instruktion, also die acht Bits von pc_if_data_in, speichert. Dies erfolgt natürlich, wenn sich der erste Automat im Zustand fetch befindet, und zwar mit der Rückflanke (der erste Automat schreitet ja mit der Vorderflanke fort).

Das Konfigurationsregister konf_reg

Die Beschreibung findet sich in pc_if.vhd im Prozeß KONFIGURATIONS_REGISTER.

Die FPGA-Bausteine der Altera FLEX8000-Familie bieten mehrere Modi an, um sie mit einer bestimmten Logik zu programmieren. Um Pins am Hilfs-FPGA einzusparen, wurde für das Prozessor-FPGA die sogenannte passive serielle Konfiguration gewählt. Wie der Name andeutet, werden die Konfigurationsdaten dabei nur bitseriell übertragen; um die Konfiguration aber desweiteren möglichst schnell über das langsame PC-Interface abzuwickeln, sollte dessen Breite von acht Bit ausgenutzt werden (wird jeweils acht Nutzbits das Befehlsbyte für Config Data vorangesendet, bedeutet dieses einen Protokoll-Overhead von 50%, was wesentlich besser ist, als nur ein Nutzbit durch ein Byte anzukündigen, also mit einem Overhead von 89% zu arbeiten). Damit wurde das Konfigurationsregister konf_reg notwendig, welches je acht vom PC gesendete Konfigurations-Bits aufnimmt und diese bitweise an den Prozessor weitergibt (es gilt progr_data konf_reg[0]).

Es handelt sich hier um ein mit der Rückflanke gesteuertes 8 Bit-Schieberegister mit den Funktionen Laden, Schieben und Speichern.

Das Konfigurationsregister tritt bei einem Config Data in Aktion - dieser Befehl durchläuft die Zustände config_waitf, config_fetch und anschließend achtmal abwechselnd config_rise und config_fall. In config_waitf wird auf ein Byte mit Konfigurationsdaten gewartet, dieses in config_fetch in konf_reg geladen. Im Folgezustand config_rise wird sich progr_dclk mit der Rückflanke auf '1' erheben, was zur Folge hat, daß der aktuelle Wert von progr_data in das FPGA übernommen werden wird. Folgerichtig wird in config_fall die Programmierclock ebenfalls mit der Rückflanke wieder auf '0' absinken; zusätzlich aber wird zu diesem Zeitpunkt das Konfigurationsregister um eine Stelle nach rechts geschoben werden (konf_reg[0] konf_reg[1] etc.). Auf diese Art wird das gesamte Byte an das FPGA übergeben werden.

Das Statusregister status_reg

Die Beschreibung findet sich in pc_if.vhd im Prozeß STATUS_REGISTER.

Dieses mit der Rückflanke aktualisierte Register enthält in vier Bereichen wichtige Informationen; die Bits des status_reg bedeuten:

Die Bits 4 bis 7 werden ständig neu gesetzt.

Die Bits 2 und 3 werden nur durch Report Status zurückgesetzt.

Die Bits 1 und 0 werden durch Config Start auf "01" gesetzt.

Das Auslesen des Statusregisters ist immer erlaubt, auch wenn das Hilfs-FPGA auf m_halt_ack oder m_reg_ack wartet.

Der Wert nach einem Reset ist "00000001" (Kein Warten, Mikroprozessor läuft, keine unzulässigen Kommandos, progr_conf_done kam noch nicht).

Das genaue Vorgehen bei dem Setzen der einzelnen Bits sollte aus der VHDL-Beschreibung ausreichend hervorgehen.

Der Multiplexer an pc_if_data_out

Die Beschreibung findet sich in pc_if.vhd im Prozeß INTERFACE_BUS.

Wie oben ausgeführt, muß das Hilfs-FPGA an den PC wahlweise den Inhalt des Statusregisters oder den gepufferten Wert von Adreß- bzw. Datenbus senden können, d.h. status_reg[7..0], areg_muxout[19..0] und dreg_muxout[15..0] müssen achtbitweise auf das Ausgangssignal pc_if_data_out[7..0] geschaltet werden können. Dies erfolgt in Abhängigkeit von den Zuständen des ersten Automaten so:

Im jeweils ersten Zustand eines Paares in der Spalte "Zustände erster Automat" ist m_stb am Schnittstellenbaustein 8255 '0', d.h. dessen Input Buffer latcht die Daten von pc_if_data; zwischen diesen Daten und m_stb ist aber eine Haltezeit notwendig, so daß im jeweils zweiten Zustand die Daten zwar weiterhin anliegen, m_stb aber wieder inaktiv ist.

Das status_reg ändert sich bereits wieder mit der Rückflanke im Zustand bericht_clear (wie der Name schon sagt), dies reicht für die Haltezeit jedoch aus.

In den Zuständen mit Namenspostfix _wait wird zusätzlich abgefragt, ob das zuletzt gesendete Byte schon aus dem Input Buffer abgeholt worden ist.

Sollen Adresse und Datum übertragen werden, werden die Zustände von areg_hi bis read_mem_lo_hold wie in der dritten Spalte aufgeführt durchlaufen; wird nur das Datum benötigt, beginnt der Vorgang bei read_mem_hi.

Der Multifunktions-Zähler counter

Die Beschreibung findet sich in pc_if.vhd im Prozeß ZAEHLER.

Dies ist ein Zähler von 0 bis (maximal) 8 für drei Verwendungszwecke:

• Bei der Konfiguration des 81500-FPGA mit Mikrorechner oder Ladedesign muß zweimal mindestens 5 s = Takte gewartet werden; dabei werden nacheinander die Zustände config, config_wait1, config2 und config_wait2 durchlaufen. In wait_for_event (also vor config) und config_wait2 wird der counter mit 0 initialisiert, in den beiden anderen Zuständen solange inkrementiert, bis er den Wert 8 erreicht.
• Sollen Adressen oder Daten vom PC byteweise übertragen (und in areg_rollin/dreg_rollin gepuffert) werden, so wird die Anzahl übertragener Bytes mitgezählt (3 bzw. 2); dabei werden die Zustände sto_wait, sto_hi und sto_lo entsprechend oft durchlaufen. In wait_for_event wird der Zähler rechtzeitig initialisiert, in sto_wait auf ein Byte vom PC gewartet, in sto_hi der Zähler inkrementiert und in sto_lo abgefragt; ist sein Wert 3 bzw. 2, wird das Empfangen beendet, ansonsten noch einmal zu sto_wait verzweigt.
• Byteweise angelieferte Konfigurationsdaten für das 81500-FPGA werden zu einzelnen Bits durch achtfaches Schieben von konf_reg (siehe 2.3.2.4); dabei wird der Zähler beim Abholen eines neuen Bytes in config_fetch initialisiert, beim Erzeugen der Vorderflanke auf progr_dclk in config_rise inkrementiert und in dem nachfolgenden config_fall abgefragt. Ist sein Wert 8, wurde das Konfigurations-Byte komplett serialisiert und der Befehl Config Data ausgeführt.

Die zwei Automaten

Die Beschreibung findet sich in pc_if.vhd in den Prozessen KONTROLLE, ACK_KONTROLLE und SYNCH.

Die zwei endlichen Automaten des PC-Interface dienen dazu, die Funktionalität des Interfaces zwischen PC und Hilfs-FPGA zur Verfügung zu stellen, ergo die in 2.2.2 genannten Kommandos zu erkennen und entsprechende Aktionen durchzuführen. Um ihre Funktionsweise grundlegend zu verstehen, muß man die wichtigsten Fakten kennen:

• Der erste Automat arbeitet wie das Steuerwerk einer CPU nach dem Schema Warten auf Befehl - Befehl holen - Befehl dekodieren - Befehl ausführen oder ablehnen - neuen Befehl holen.
• Den ersten drei Stadien der Befehlsabarbeitung entsprechen die Zustände wait_for_event, fetch und decode. Ein nicht definierter Befehl führt nach err_unknown, ein nur momentan verbotener nach err_notnow und zulässige Befehle in diverse Folgezustände, die alle wieder nach wait_for_event führen.
• Um Inkonsistenzen und Kollisionen auf den Bussen zu vermeiden sowie den Mikroprozessor schrittweise beobachten zu können, kann dieser in den drei Modi running, halted und single step betrieben werden. Hierzu gibt es die Befehle Halt, Go, Single Step und Single Instruction, die den in status_reg[5..4] gespeicherten Modus setzen.

Die momentane Zulässigkeit eines Befehles ist abhängig von diesem Modus.

• Der erste Automat führt nur terminierende Befehle aus, die also nach endlicher Anzahl Takte enden (weil ihr Verlauf genau bestimmt ist). Ausnahmen: Bei Store Address/Data und Config Data werden nach dem Befehlsbyte noch Datenbytes vom PC erwartet. Daß diese verlorengehen ist aber durch den Schnittstellenbaustein (mit Output Buffer) und daß diese gar nicht erst gesendet werden, durch die ausgetestete Software ausgeschlossen.
• Es gibt Befehle, die nicht terminieren müssen, weil sie Handshaking-Signale als Affirmation des Mikroprozessors erwarten, deren Erscheinen natürlich von dessen Design abhängig ist. Diese Befehle sind Halt/Single Instruction (Warten auf m_halt_ack) und Read Register (Warten auf m_reg_ack).
• Der zweite Automat wird für die Ausführung solcher Befehle gestartet. Deren Bearbeitung, insbesondere also das Warten auf unbestimmte Zeit, erfolgt parallel zum Ablauf des ersten Automaten.
• Während der zweite Automat arbeitet, kann der erste die Befehle Bericht und Abort ausführen (andere sind solange untersagt). Durch "Bericht" wird das Statusregister an den PC gesandt, in dem auch festgehalten wird, auf welches Handshaking-Signal der zweite Automat (noch) wartet; Abort erlaubt das Zurücksetzen des zweiten Automaten bei Ausbleiben des Signals vom Prozessor.

Beide Automaten werden mit der Vorderflanke getaktet, die Startzustände lauten wait_for_event und warten. Die Abfrage des Zustands des jeweils anderen Automaten erfolgt gepuffert durch c_state_buffer bzw. c_state2_buffer (Aktualisierung mit Rückflanke).

Die Abläufe in den Automaten und ihre Abhängigkeit voneinander finden sich visualisiert in Kapitel 3.5.1 Automaten im PC-Interface. Zur weiteren Erklärung der Details sei auf den ausführlich dokumentierten Code verwiesen.

Vermeidung von Verklemmungen durch Teilparallelität

Besonders in der Testphase von Prozessor-Designs, Hilfs-FPGA und PC-Software war es möglich, daß eine bestimmte Form der Verklemmung auftrat. Dabei sendet bei einem Handshaking-Protokoll die eine Seite ein initiierendes Signal aus, oder meint, dieses zu tun, und wartet anschließend auf das entsprechende affirmative Signal, ohne dieses jedoch zu empfangen. Um solche Verklemmungen zu vermeiden, war es notwendig, sich zu überlegen, daß in der Kontrollhierarchie PC Hilfs-FPGA Mikroprozessor sechs Vorgänge in dieser Hinsicht kritisch sind:

1. Der PC sendet ein Byte (Befehl oder Datum) an das Hilfs-FPGA via Schnittstellenbaustein 8255, dieser signalisiert dieses dem Hilfs-FPGA durch m_obf ''0' (output buffer full), doch das Byte wird nicht abgeholt (m_ack bleibt '1').
   
2. Das Hilfs-FPGA erwartet ein Byte (Befehl oder Datum) vom PC via Schnittstellenbaustein 8255, doch dieses (signalisiert durch m_obf ''0') bleibt aus.
   
3. Das Hilfs-FPGA sendet ein Byte (Datum) an den PC via Schnittstellenbaustein 8255, dieser signalisiert dieses dem PC durch ibf ''1' (input buffer full), doch das Byte wird nicht abgeholt.
   
4. Der PC erwartet ein Byte (Datum) vom Hilfs-FPGA via Schnittstellenbaustein 8255, doch dieses (signalisiert durch ibf ''1') wird nicht in den Schnittstellenbaustein geschrieben (m_stb bleibt '1').
   
5. Das Hilfs-FPGA soll den Prozessor in den Modus halted bringen. Dazu zieht es m_halt auf '0' und wartet auf die Bestätigung durch m_halt_ack '0', doch diese bleibt aus.
   
6. Das Hilfs-FPGA soll ein Register des Prozessors auslesen. Dazu zieht es m_reg_req auf '0' und wartet auf die Bestätigung durch m_reg_ack '0', doch diese bleibt aus.

Wie können diese Verklemmungen, die in der Praxis leicht dazu führen können, schwerwiegende Entwurfsfehler zu vermuten, da eine Komponente offenbar nicht (mehr) reagiert, aufgelöst werden, und was sind ihre Ursachen?

1. (PC sendet Byte)

Mögliche Ursachen: Da das Hilfs-FPGA stets m_obf abfragt, wenn es einen Befehl zu Ende abgearbeitet hat, was ja nur eine Frage der Zeit ist, muß es selbst auf ein Signal warten. Da weiterhin aber das Warten auf m_halt_ack und m_reg_ack wegen der Fälle 5. und 6. nunmehr parallel zum Auslesen des Schnittstellenbausteines durchgeführt wird, bleibt nur ein Warten auf ibf = '0' als Ursache, d.h. das Hilfs-FPGA soll ein Byte empfangen, möchte aber selbst gerade eines senden, was nicht möglich ist, da bereits ein nicht-abgeholtes Byte im Schnittstellenbaustein wartet. Ursache kann nur ein Irrtum bei der Abstimmung der Software im PC mit dem PC-Interface im Hilfs-FPGA sein, d.h. Senden eines falschen Befehlswortes, welches eine Antwort bedingt, mit der nicht gerechnet wird, oder Irrtum über die Anzahl zurückgelieferter Bytes.

Lösung: Mit einem timer ist in der PC-Software leicht der Zeitpunkt abzuwarten, an dem der längstmögliche Befehl im Hilfs-FPGA abgearbeitet worden sein müßte (Config Start durchläuft sieben Zustände in 21 Takten). Wurde das Byte danach immer noch nicht abgeholt, so kann nur eine Verklemmung wegen Wartens auf ibf vorliegen (zu der anderen möglichen Ursache "Totalabsturz des Hilfs-FPGAs" siehe 2.4.4). Es müssen nun nur sukzessive solange Bytes aus dem Schnittstellenbaustein ausgelesen werden, bis ibf nicht mehr auf '1' geht, d.h. das Hilfs-FPGA nicht mehr sendet. Diese Lösung hat im Gegensatz zum Senden eines Hardware-Resets an das Hilfs-FPGA den Vorteil, daß das Statusregister hernach noch nicht gelöscht wurde.

2. (Hilfs-FPGA erwartet Byte)

Mögliche Ursachen: Irrtümer bei der Abstimmung von Software im PC mit PC-Interface im Hilfs-FPGA.

Lösung: Dieser Fehler ist nur indirekt durch "Verschwinden" von Befehlen/Daten zu entdecken. Wartet das Hilfs-FPGA nämlich noch auf ein Byte, so wird natürlich auch ein Report-Befehl, der die Lage klären sollte, als das fehlende Datum genommen. Bei Befehlen aus mehreren Bytes, z.B. Store Data, können Hilfs-FPGA und PC auch quasi desynchronisiert werden, so daß das eigentliche Befehlsbyte noch irgendwelche Lücken stopft, ein nachfolgendes Datenbyte aber als Befehl interpretiert wird, was sich irgendwann als aufgetretener illegaler oder momentan nicht zulässiger Befehl im Statusregister erraten läßt. Ein Reset für das Hilfs-FPGA erscheint dann angebracht.

3. (Hilfs-FPGA sendet Byte)

Mögliche Ursachen: Dies ist die andere Sicht des Falles 1., siehe dort.

Lösung: Siehe 1. .

4. (PC erwartet Byte)

Mögliche Ursachen: Irrtümer bei der Abstimmung von Software im PC mit PC-Interface im Hilfs-FPGA; Irrtum bezüglich des Lauf-Modus, in dem sich Prozessor und Hilfs-FPGA befinden. Letzterer Fall bedeutet, daß ein an das Hilfs-FPGA gerichteter Befehl deswegen keine Bytes zurückliefert, weil er im momentanen Modus (z.B. running) des Hilfs-FPGAs gar nicht erlaubt ist und somit ignoriert wird (aber das Statusregister beeinfluÿt).

Lösung: Auf jeden Fall sollte man einen Report-Befehl senden, um zu überprüfen, ob der angenommene Modus des Hilfs-FPGAs auch tatsächlich der aktuelle ist. Ist dieses der Fall und der gewünschte Befehl tatsächlich zulässig, bleiben die Irrtümer der ersten Art als Erklärung.

5. (Hilfs-FPGA wartet auf m_halt_ack)

Mögliche Ursachen: Anhalten des Prozessors fehlerhaft implementiert; m_halt ändert sich zu kurz.

Lösung: Um auch bei fehlerhafter/noch nicht vorhandener Implementierung des Haltevorganges das Hilfs-FPGA weiter benutzen zu können, wurde das Warten auf die Bestätigung durch m_halt_ack parallel zu der Abarbeitung der anderen Befehle des PC-Interfaces, insbesondere Report und Abort, verwirklicht. Ein sinnloser Wartezustand kann so bei Ablauf eines timers mit Report festgestellt und mit Abort abgebrochen werden. Ein längeres Haltesignal wird durch das Kommando halt1 möglich.

6. (Hilfs-FPGA wartet auf m_reg_ack)

Mögliche Ursachen: Auslesefähigkeit für Register fehlerhaft implementiert.

Lösung: Um auch bei fehlerhafter/noch nicht vorhandener Implementierung des Auslesevorganges das Hilfs-FPGA weiter benutzen zu können, wurde das Warten auf die Bestätigung durch m_reg_ack parallel zu der Abarbeitung der anderen Befehle des PC-Interfaces, insbesondere Report und Abort, verwirklicht. Ein sinnloser Wartezustand kann so bei Ablauf eines timers mit Report festgestellt und mit Abort abgebrochen werden.

Die Fälle 1. bis 4. können lediglich über Software erkannt werden (der 2. auch nur mit Mühen). Dies erklärt die Entwurfsentscheidung, "nur" die letzten beiden Fälle (Warten auf m_halt_ack oder m_reg_ack) durch parallele Verarbeitung in der Hardware zu entschärfen.