Sicherer Halt inklusive

Der „Nexus“-Block

Nexus bildet den zentralen Block, der auf großen SoCs einen unbehinderten Datenfluss ermöglicht. Er besteht aus einem nicht-blockierenden Mehrfachschalter, der quasi gleichzeitig mehrere Datenquellen und Senken mit unterschiedlichen Datenraten und Blocklängen miteinander verbindet, und das bei relativ kleinem Zusatzaufwand. Zusatzblöcke um das Verbindungsnetzwerk herum erledigen die Steuerung und die Synchronisation.

Festlegung der „Vorfahrt“

Nexus ist in asynchroner Technologie implementiert. Damit muss auch der Arbiter auf diese Technik abgestimmt sein. Ein typischer synchroner Arbiter ist z.B. ein Zustandsautomat, der den Eingangsstatus per Takt abtastet und dann eine deterministische Entscheidung über die Reihenfolge der Abarbeitung trifft. Der asynchrone Arbiter muss dieselben Entscheidungen treffen, aber auf Basis der im Zeitablauf völlig zufällig auftretenden Anforderungen. Die Arbiter-Architektur ist deshalb vollkommen verschieden; der Nexus-Arbiter behandelt die Daten auf einer „First-come-First-serve“-Basis, wenn die jeweilige Zieladresse gerade frei ist. Sollte der Port gerade besetzt sein, werden stattdessen andere, bereits anstehende Daten durchgeschaltet und zwar auf „faire“ Weise, basierend auf einem „Seitzer“-Arbiter, bestehend aus zwei über Kreuz gekoppelten NAND-Gattern mit zusätzlichem Filter gegen Metastabilität. Die Mehrfachauswahl für die 16 Kanäle wird durch die Implementierung einer Baumstruktur erreicht.

Es ergibt sich damit beim Nexus-System das folgende Datentransfer-Verhalten: Ist „wenig“ Datenverkehr, werden alle Daten so verteilt, wie sie ankommen, quasi-gleichzeitig. Bei stärkerer Belastung wird der Reihe nach alternativ übertragen, aber alle Kanäle werden ohne Ausnahme bedient. Im schlimmsten Fall wird bei der 16-Port-Implementierung der Kanal mit der stärksten Aktivität 50 % der verfügbaren Zeit für seine Übertragung erhalten und alle anderen Kanäle teilen sich den Rest. Ein solches Verhalten gilt allerdings nur, wenn konstant zuviel Verkehr herrscht. Es wird also „gebremst“, nicht blockiert.

Implementierungs-Alternativen

Die verfügbare Standard-Implementierung von 36 bit pro Port und 16 bidirektionalen Ports hat sich aus den Anforderungen ergeben. Es können dadurch 16 bidirektionale 32-bit-Busse über Nexus gleichzeitig kommunizieren, wobei die restlichen 4 der 36 bit zum Beispiel als Parity oder als zusätzliche Datenbits eingesetzt werden können.

Nexus ist nicht auf diese Organisation fixiert, sondern lässt sich auch auf andere Applikationen optimieren:

• Anzahl der Ports: Sinnvolle Implementierungen liegen zwischen 8 und 32.
• Anzahl der Bits pro Port: 8 bis 128.

In allen Fällen muss betrachtet werden:

• wie viel Platz die Verbindungen auf dem Chip einnehmen,
• welche Leistungsaufnahme sich im Maximalfall ergibt,
• ob eine Kaskadierung von kleineren Nexus-Blöcken vorteilhafter ist im Vergleich zu einem großen Schalter, der sehr viele lokale Verbindungen erfordert.

Meist müssen nicht alle Kanäle mit maximalem Datendurchsatz kommunizieren. In einem solchen Fall können mehrere langsamere Kanäle auf einen schnellen Nexus-Port gemultiplext werden und erfordern damit weniger Siliziumfläche. Dasselbe gilt auch auf Wortbasis, wenn z.B. zwei 8-bit-, ein 16-bit- und vier Einzelbit-Signale zu einem 36-bit-Wort zusammengesetzt werden und sich dadurch die erforderliche Kanalzahl reduziert.

Der F1-Chip

Im F1-Chip (Bild 3) wurden die wichtigsten Funktionen zusätzlich zum Nexus-System integriert, um einen Prototypen aufbauen zu können und zur Unterstützung des Systemaufbaus, speziell, um die Kommunikation zwischen den externen synchronen Kanälen und dem asynchronen Datentransfer im Nexus-Block zu ermöglichen:

• Takt-Generator,
• Taktdomänen-Konverter zur Synchron-Asynchron-Wandlung,
• DDR-SDRAM-Interface,
• 2 On-Chip-SRAMs 4 K x 36 bit,
• Asynchron-Synchron-Wandlung,
• Test-Interfaces,
• PCI-Daten-Interface.

1. Sicherer Halt inklusive
2. Der „Nexus“-Block
3. Das F1-Testboard