Kapitel 5 – Timing:

Es gilt: Bei hinreichend langsamem Takt funktioniert der Rechner.

Frage: Wie schnell kann man den Rechner takten? Wie lange muss ein Takt mind. sein?

→ Ersetze idealisiertes Timing durch exakte Timinganalyse
→ Gesucht: Untere Grenze für Zykluszeit

(ReTI-Architektur: PC, I/E_ALU, Befehl/Daten fetch/execute mit Phasen P0–P3, N0–N3 und Kontrollsignalen /SMDdoe, s0, s1, E, A, D, L, Icken, rcken, /PCload, /PCclear, ck, /SMw)

Schritte der Analyse

Wir werden uns auf Compute-Befehle beschränken.

Timing der Kontrolllogik (1/3)

Setupzeit der Dateneingänge bis ck ist , Setupzeit der Dateneingänge bis /ck ist .

Dateneingänge () müssen rechtzeitig bereit sein. Alle Dateneingänge sind Ausgangssignale von FFs, die mit ck getaktet werden.

Timing der Kontrolllogik (2/3)

Wähle eine beliebige steigende Taktflanke als zeitlichen Bezugspunkt.

Die Dateneingänge sind also bereit zur Zeit (Verzögerung eines D-FF).

Die nächste steigende Taktflanke von /ck ist bei , die nächste steigende Taktflanke von ck bei .

Für /ck:

öü

Für ck:

ü

Timing der Kontrolllogik (3/3)

Hold-Zeiten sind unkritisch:

Constraints

Compute-Befehle

Am zeitkritischsten ist Compute memory!

(ReTI-Schaltplan: PC, IN1, IN2, ACC, ALU, I, SRAM mit Bussen A, D, DI, R, L)

; hier:

(ReTI-Schaltplan mit nummerierten Analysepunkten 1–10)

Analyse allgemein

Beginn der Analyse bei von Fetch als zeitlicher Bezugspunkt. Bei von Fetch wird der Befehl ins Instruktionsregister übernommen.

(ReTI Timing-Diagramm: Phasen P0–P3, N0–N3)

I-Ausgänge (1/2)

I-Ausgänge gültig bei:

wird über Treiber IAd auf Adressbus gegeben. ist eine Konstante und steht daher ebenfalls zu bereit.

Constraints

I-Ausgänge (2/2)

IAd enabled bei von Execute, d. h. /IAdoe aktiv zur Zeit:

/IAdoe wird verteilt auf 32 Tristate-Treiber von IAd, also wieder 4 Treiber mit Tiefe 1. /IAdoe kommt bei IAd an zur Zeit:

schon gültig vor Aktivierung von IAd bei Punkt 2, falls:

Constraints

Gültiges A (1/2)

→ gültig zur Zeit:

Constraints

Gültiges A (2/2)

ASMd immer enabled → nur Treiber-Verzögerung berücksichtigt.

→ an SM bei:

Constraints

Daten am Speicherausgang (1/3)

Lesezugriffszeit von SRAM: (siehe Daten von CY7C1079DV33)

→ Gültige Daten am Speicherausgang bei:

Das ist aber nur korrekt, wenn der Ausgangstreiber durch /SMDdoe rechtzeitig enabled ist!

Daten am Speicherausgang (2/3)

/SMDdoe aktiviert zur Zeit .

Daten am Speicherausgang aufgrund Treiber-Enable gültig zur Zeit:

⇒ Daten am Speicherausgang gültig spätestens zur Zeit:

Daten am Speicherausgang (3/3)

Daten am Speicherausgang gültig zur Zeit .

Bedingung für :

Wir nehmen ab jetzt an, dass die Taktperiode ist und rechnen mit weiter.

(Es gilt auf jeden Fall . Sollte sich später ergeben, dass die minimale Taktperiode , dann müssten wir die Rechnung nochmals korrigieren.)

Constraints

Daten auf R

DRd enabled bei von Execute, also einen Takt vor Ausgangstreiber von SM.

→ Enable nicht kritisch

→ Daten auf R spätestens bei:

ö

Constraints

Daten auf L

Registerausgänge schon seit letzter Execute-Phase gültig.

→ nicht kritisch

Treiber rLd enabled bei von Execute, d. h. wie auch bei DRd ist Zeit zum Enablen unkritisch im Vergleich zu .

, cin

, cin werden durch den kombinatorischen Schaltkreis der Kontrolllogik aus berechnet.

I-Ausgänge aber schon gültig bei . Verzögerungszeit des kombinatorischen Schaltkreises .

, cin gültig spätestens bei .

→ völlig unkritisch verglichen mit .

Constraints

Voraussetzungen für die exakte Timinganalyse von Compute memory: ALU

Analyse der ALU (32-Bit mit Conditional Sum) unter folgender Annahme:

ALU-Ausgänge

Spätestens gültig bei:

Constraints

DI

/ALUDIdoe wird wie /SMDdoe aktiviert bei von Execute. Daten kommen an ALUDId später an als am internen SRAM-Treiber. Enable-Zeit von ALUDId jedoch kürzer als bei SRAM.

Mit ist auf jeden Fall auch für ALUDId gewährleistet, dass Treiber enabled, wenn Daten kommen.

→ Berücksichtige nur Treiberverzögerung.

→ Gültig spätestens bei:

Constraints

Datenübernahme in Register

Clocksignale bei von Execute → steigende Flanke bei .

Minimale Taktperiode wird aus Setup-Zeit von berechnet (Setup-Zeit am größten, wenn ).

(ReTI Timing-Diagramm: Phasen P0–P3, N0–N3)

Constraints

Timing: Zähler

Aus einer Analyse des Zählers in einer Implementierung gemäß Kapitel 4.1 (aber mit zusätzlichem Clock-Enable für das Register!) ergeben sich folgende Zeiten:

Setup-Zeit von Zähler

Setup-Zeit: (siehe Aufbau Zähler)

→ Bedingung:

Constraints

Es bleiben zu beachten:

Hold-Zeit

Maximal bei , .

Unproblematisch, da alle Treiber noch mindestens Takt nach rck enabled sind.

(ReTI Timing-Diagramm: Phasen P0–P3, N0–N3)

Setup- und Hold-Zeiten von rcken

rcken aktiv bei von Execute, inaktiv bei von Execute, d. h. aktiv von:

Setup-Zeit: Für alle :

(unkritisch im Vergleich zu bisherigen Constraints)

Hold-Zeit: Für alle :

(Analog auch für alle anderen Takte.)

Setup- und Hold-Zeiten /PCload beim Zähler

/PCload (benötigt, wenn neue Werte in Zähler kommen) aktiv bei von Execute, inaktiv bei von Fetch.

(ReTI Timing-Diagramm: Phasen P0–P3, N0–N3)

Bedingungen für Setup- und Hold-Zeiten /PCload beim Zähler

Setup: Am kritischsten, wenn /PCload seinen Wert bei der vorangegangenen Taktflanke geändert hat, d. h. bei von Execute bzw. von Fetch.

Hold: Am kritischsten, wenn sich /PCload ändert, d. h. bei von Execute und von Fetch.

→ Beide unkritisch im Vergleich zu bisherigen Constraints.

Fazit: Zykluszeit und Befehlsrate

Vorläufiges Ergebnis: Falls sich durch andere Befehle keine schärferen Bedingungen an die Zykluszeit ergeben, dann lautet sie:

Taktfrequenz:

8 Takte pro Befehl → 18.5 Millionen Befehle pro Sekunde, d. h. Befehlsrate von 18.5 MIPS (= Million Instructions per Second).

Anmerkungen zur Timing-Analyse

Eine „echte" Timing-Analyse müsste noch Leitungslaufzeiten auf dem Chip berücksichtigen. Dazu muss dann aber schon das Layout des Chips bekannt sein, um die Leitungslängen und -kapazitäten zu berechnen.

Leitungslaufzeiten waren früher bei einem Aufbau mit diskreten Bausteinen vernachlässigbar, sind es bei den heutigen Technologien aber nicht mehr.

⇒ Exakte Timing-Analysen sind heute daher kaum ohne maschinelle Unterstützung durchführbar.

Synthesetools sind in der Lage, durch Optimierung der Treiberstärken von Grundgattern (verschiedene Versionen in der Bibliothek!) Laufzeiten zu minimieren.

Wird das SRAM nicht auf dem Chip integriert (d. h. stattdessen ein kommerzielles externes SRAM angeschlossen), dann muss man noch Verzögerungszeiten für I/O-Pads des Chips mit eventueller Anpassung von Spannungspegeln berücksichtigen.

Ausblick 1/2

Beschleunigung:

Ausblick (2/2)

Fehlerbehandlung:

Fehlertoleranz:

Verifikation:

Architekturkonzepte: