DE19735880A1

DE19735880A1 - Verfahren und Vorrichtung zum Verarbeiten von Videodaten

Info

Publication number: DE19735880A1
Application number: DE19735880A
Authority: DE
Inventors: Cliff Reader; Jae Cheol Son; Amjad Qureshi; Le Trong Nguyen
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 1996-08-19
Filing date: 1997-08-19
Publication date: 1998-05-14
Also published as: KR19980018215A; CN1189058A; TW436710B; JP4290775B2; JPH1093961A; CN1523895A; CN1145362C; KR100262453B1

Description

Die vorliegende Erfindung betrifft die Datenverarbeitung durch Computer, insbesondere die Verarbeitung von Videodaten durch Computer.

Computer werden zum Komprimieren und Ent- bzw. Dekomprimieren von Systemdaten verwendet. Systemdaten schließen Videodaten ein, die Bilder von Stand- und/oder Bewegungsbildern einschließen. Die Systemdaten können ebenfalls Audiodaten enthalten, z. B. eine Tonaufnahme eines Films.

Es ist Aufgabe der Erfindung Verfahren und Schaltungen vorzusehen, die eine schnellere Verarbeitung von Videodaten ermöglichen.

Die vorstehende Aufgabe wird durch die Vorrichtung nach Anspruch 1 bzw. 3 bzw. durch das Verfahren nach Anspruch 4 bzw. 6 gelöst.

Vorteilhafte Ausgestaltungen der Erfindung sind in den Unteransprüchen angegeben.

Die Erfindung sieht Verfahren und Schaltungen vor, die ein schnelles Verarbeiten von Videodaten ermöglichen. Bei einigen Ausführungsbeispielen weist eine Computervorrichtung der Erfindung drei Prozessoren auf - einen Skalarprozessor, einen Vektorprozessor und einen Bitstrom-Prozessor - , die gleichzeitig arbeiten können. Beim Codieren oder Decodieren von Videodaten führt der Vektorprozessor Operationen durch, die durch einen Einzelbefehl-Mehrdaten-Prozessor (SIMD-Prozessor) effizient ausgeführt werden können. Solche Operationen schließen ein: 1) eine lineare Datenumformung, wie eine diskrete Cosinus- Umformung (DCT), und 2) eine Bewegungskompensation. Der Bitstrom-Prozessor führt Operationen aus, die eher Operationen einschließen, die an speziellen Bits durchgeführt werden als an Wörtern oder Halbwörtern. Solche Operationen schließen ein Huffman- und ein RLC-Codieren oder -Decodieren ein, die z. B. bei den MPEG-1-, MPEG-2-, H.261- und H.263-Standards verwendet werden. Der Skalarprozessor führt die Highlevel-Videoverarbeitung (die übergeordnete Videoverarbeitung, z. B. die Verarbeitung auf Bildebene) durch, synchronisiert den Betrieb des Vektorprozessors und des Bitstrom-Prozessors und steuert die Schnittstelle zu externen Einrichtungen.

Bei einigen Ausführungsbeispielen kann die Computervorrichtung mehrere Datenströme gleichzeitig verarbeiten. Folglich kann der Nutzer der Computervorrichtung eine Videokonferenz mit zwei oder mehreren Teilnehmern führen. Mehrere Datenströme können gleichzeitig verarbeitet werden, weil der Bitstrom- Prozessor Kontexte schalten kann, um gleichzeitig verschiedene Datenströme in Echtzeit zu codieren oder decodieren.

Bei einigen Ausführungsbeispielen sind der Skalarprozessor und der Vektorprozessor programmierbar in dem Sinne, daß jeder der beiden Prozessoren so programmiert werden kann, daß er einen einzigen arithmetischen oder boolschen Befehl ausführt. Der Bitstrom-Prozessor ist nicht programmierbar in dem Sinne, daß der Bitstrom-Prozessor nicht so programmiert werden kann, daß er einen einzigen arithmetischen oder boolschen Befehl ausführt. Statt dessen kann der Bitstrom-Prozessor so programmiert werden, daß er eine komplette Videodatenverarbeitungsoperation an einem Satz von Videodaten ausführt. Dadurch, daß der Bitstrom- Prozessor nicht programmierbar ist, um einen einzigen arithmetischen oder boolschen Befehl auszuführen, wird es ermöglicht, daß der Bitstrom-Prozessor schneller ist. Die Programmierbarkeit des Skalar- und des Vektorprozessors erleichtert das Anpassen der Vorrichtung an Änderungen bei den Videodatencodierungs- und Decodierungsstandards.

Die Erfindung wird nachstehend anhand der Fig. näher erläutert. Es zeigen:

Fig. 1 ein Blockdiagramm einer Multimedia-Karte gemäß der Erfindung,

Fig. 2 ein Blockdiagramm eines Multimedia-Prozessors gemäß der Erfindung,

Fig. 3 ein Blockdiagramm eines Bitstrom-Prozessors, der Teil des Prozessors von Fig. 2 ist,

Fig. 4-6 Blockdiagramme von Computervorrichtungen gemäß der Erfindung,

Fig. 7 eine Festprogramm-Architektur bzw. Firmware- Architektur beim Prozessor von Fig. 2,

Fig. 8-9 Adressenabbilder für die Vorrichtung von Fig. 1,

Fig. 10 ein Blockdiagramm des DSP-Kerns (digitaler Signalprozessor-Kern) des Prozessors von Fig. 2,

Fig. 11 eine Pipeline, die bei einem Vektorprozessor verwendet wird, der Teil des Prozessors von Fig. 2 ist,

Fig. 12 ein Funktionsblockdiagramm des Vektorprozessors von Fig. 11,

Fig. 13 Ausführungsdatenwege beim Vektorprozessor von Fig. 11,

Fig. 14 Lade- und Speicherdatenwege beim Vektorprozessor von Fig. 11,

Fig. 15 ein Blockdiagramm eines Cache-Systems des Prozessors von Fig. 2,

Fig. 16 einen Befehls-Datencache beim Cache-System von Fig. 15,

Fig. 17 eine Datenweg-Pipeline bei einer Cache- Steuereinheit beim Prozessor von Fig. 2,

Fig. 18 Datenwege für eine Adreß-Verarbeitungs-Pipeline bei einer Cache-Steuereinheit beim System von Fig. 2,

Fig. 19-22 Status- bzw. Zustandsmaschinen beim Prozessor von Fig. 2,

Fig. 23 Adreßformate, die beim Cache-System von Fig. 15 verwendet werden,

Fig. 24 einen Bus beim Prozessor von Fig. 2,

Fig. 25 eine Schlichtungs-Steuereinheit (Arbitration- Steuereinheit) beim Prozessor von Fig. 2,

Fig. 26-29 Zeitablaufdiagramme für den Prozessor von Fig. 2,

Fig. 30-32 Speicheranfrage-Signale beim Prozessor von Fig. 2,

Fig. 33 eine Bus-Schlichtungs-Steuereinheit beim Prozessor von Fig. 2,

Fig. 34-36 Zeitablaufdiagramme für den Prozessor von Fig. 2,

Fig. 37-38 Bus-Schnittstellen-Schaltungsaufbauten beim Prozessor von Fig. 2,

Fig. 39-40 virtuelle Datenübertragungsblock- bzw. Frame- Zwischenspeicher (VFB) für die Vorrichtung von Fig. 1,

Fig. 41 Bus-Schnittstellen-Schaltungsaufbauten für die Vorrichtung von Fig. 1,

Fig. 42-43 eine Speichersteuereinheit für die Vorrichtung von Fig. 1,

Fig. 44 eine Adreßsteuereinheit für die Vorrichtung von Fig. 1,

Fig. 45 und 46 Formate, die bei der Vorrichtung von Fig. 1 verwendet werden,

Fig. 47 eine Zustandsmaschine bei der Vorrichtung von Fig. 1,

Fig. 48 ein Blockdiagramm einer Datensteuereinheit für die Vorrichtung von Fig. 1,

Fig. 49-51 Zeitablaufdiagramme für die Vorrichtung von Fig. 1,

Fig. 52-53 Einrichtungs-Schnittstellen-Schaltungsaufbauten beim Prozessor von Fig. 2,

Fig. 54-56 Blockdiagramme von Teilen der Vorrichtung von Fig. 1,

Fig. 57-59 Register bei der Vorrichtung von Fig. 1,

Fig. 60 Frame-Zwischenspeicher und Videofenster bei der Vorrichtung von Fig. 1,

Fig. 61 ein Zeitablaufdiagramm für die Vorrichtung von Fig. 1,

Fig. 62 ein Register bei der Vorrichtung von Fig. 1,

Fig. 63 ein Zeitablaufdiagramm für die Vorrichtung von Fig. 1, und

Fig. 64-66 Zwischenspeicher, die bei der Vorrichtung von Fig. 1 verwendet werden.

Fig. 1 zeigt eine Multimedia-Karte 100, die einen Multimedia-Prozessor 110 aufweist. Bei einigen Ausführungsbeispielen ist der Prozessor 110 ein MSP-1EX- Prozessor (Markennamen-Prozessor), dessen Spezifikation von Samsung Semiconductor Corporation in San José, Kalifornien, vorgegeben ist. Der Prozessor MSP-1EX ist im Anhang A beschrieben.

Der Prozessor 110 kommuniziert mit einem Hauptrechner- bzw. Hauptcomputersystem (nicht dargestellt) über einen lokalen Bus 105. Bei einigen Ausführungsbeispielen ist der Bus 105 ein 32-Bit-PCT-Bus mit 33 MHz. Ein digitaler Videodatenausgang des Prozessors 110 ist mit einem D/A-Wandler 112 (Digital/Analog-Wandler) verbunden. Zusätzlich zu einem Videoanteil können die digitalen Videodaten einen Audioanteil einschließen, z. B. eine Tonaufnahme eines Films. Der Ausgang des Wandlers 112 ist zur Verbindung mit einem Fernsehapparat (nicht dargestellt) oder einem anderen System, das Analogdaten verarbeitet, geeignet. Bei einigen Ausführungsbeispielen schließt der Prozessor 110 ebenfalls einen Eingangsanschluß zum Empfangen von digitalen Videodaten von einem A/D-Wandler (Analog/Digital-Wandler) auf (siehe die Fig. 4-6).

Der Prozessor 110 ist mit einem Codec 114 (Codierer- Decodierer) verbunden. Der Codec 114 empfängt analoge Audiodaten von einem Bandaufzeichnungsgerät (nicht dargestellt) oder einer anderen Einrichtung. Der Codec 114 empfängt analoge Telefondaten von Telefonleitungen (nicht dargestellt) . Der Codec 114 digitalisiert die Analogdaten und überträgt diese zum Prozessor 110. Der Codec 114 empfängt digitale Daten vom Prozessor 110, wandelt diese Daten in eine analoge Form um und überträgt die analogen Daten nach Bedarf.

Der Prozessor 110 ist über einen Bus 122 mit einem Speicher 120 verbunden. In Fig. 1 ist der Speicher 120 ein SDRAM (ein synchroner, dynamischer Schreib-Lese-Speicher) und der Bus 122 ist ein 64-Bit-Bus mit 80 MHz. Andere Speicher, Busbreiten und Busgeschwindigkeiten werden bei anderen Ausführungsbeispielen verwendet. Asynchrone Speicher und Busse werden bei einigen Ausführungsbeispielen verwendet.

Einige Ausführungsbeispiele der Karte 100 werden in der US- Patentanmeldung mit dem Titel "Multiprocessor Operation in a Multimedia Signal Processor" (Anwaltsdokument Nr. M-4354 US), die von Le Nguyen gleichzeitig mit der Prioritätsanmeldung der vorliegenden Anmeldung, die hiermit eingeschlossen werden soll, eingereicht wurde.

Fig. 2 ist ein Blockdiagramm eines Ausführungsbeispiels des Prozessors 110. Der Prozessor 110 schließt einen Skalarprozessor 210, einen Vektorcoprozessor 220 ("VP") und einen Bitstrom-Prozessor 245 ("BP") ein. Bei einigen Ausführungsbeispielen ist der Prozessor 210 ein 32-Bit- RISC-Prozessor, der bei 40 MHz arbeitet und mit dem bekannten Standard-ARM7-Befehlssatz übereinstimmt. Der Vektorprozessor 220 ist ein Einzelbefehl-Mehrdaten- Prozessor (SIMD-Prozessor), der bei 80 MHz arbeitet und 288-Bit-Vektorregister aufweist. Ein Ausführungsbeispiel des VP 220 ist in der US-Patentanmeldung mit dem Titel "Efficient Context Saving and Restoring in a Multitasking Computing System Environment" (Anwaltsdokument Nr. M-4365 US), die von Song et al. zur gleichen Zeit wie die Prioritätsanmeldung der vorliegenden Anmeldung eingereicht wurde, und hier durch Bezugnahme eingeschlossen werden soll. Die Prozessoren 210 und 220 können so programmiert werden, daß sie einen einzigen arithmetischen oder boolschen Befehl oder eine Folge von solchen Befehlen ausführen.

Bei einigen Ausführungsbeispielen wird es dem Bitstrom- Prozessor 245 nicht ermöglicht, so programmiert zu werden, daß er einen einzigen arithmetischen oder boolschen Befehl ausführt, um bei der Verarbeitung von Videodaten eine hohe Geschwindigkeit zu erreichen. Insbesondere kann der BP 245 nicht so programmiert werden, daß er einen einzelnen Befehl ausführt, wie z. B. "ADD", "OR", "ADD AND ACCUMULATE" usw. Statt dessen kann der BP 245 angewiesen werden, eine Videodaten-Verarbeitungsoperation wie in Anhang A, Kapitel 10, beschrieben auszuführen. Gleichzeitig können der Skalarprozessor 210 und der Vektorprozessor 220 so programmiert werden, daß sie einen einzelnen arithmetischen oder boolschen Befehl ausführen. Daher kann der Prozessor 110 an Änderungen bei Videostandards angepaßt werden.

Wie dies in Fig. 2 dargestellt ist, sind der Skalarprozessor 210 und der Vektorprozessor 220 mit einem Cache-Subsystem 230 verbunden. Das Cache-Subsystem 230 bzw. Cache-Untersystem ist mit einem Bus 240 ("IOBUS") und einem Bus 250 ("FBUS") verbunden. Bei einigen Ausführungsbeispielen ist der IOBUS 240 ein 32-Bit-Bus mit 40 MHz und der FBUS 250 ist ein 64-Bit-Bus mit 80 MHz.

Der IOBUS 240 ist mit dem Bitstrom-Prozessor 245, einer Unterbrechungssteuereinheit 242 bzw. -steuereinrichtung, einer Duplex-UART-Einheit 243 (Anpassungsschaltungseinheit zur Umsetzung von paralleler zur serieller Datenübertragung) und vier Zeitgebern 242 verbunden. Der FBUS 250 ist mit einer Speichersteuereinheit 258 verbunden, die wiederum mit dem Speicherbus 122 verbunden ist (Fig. 1). Der FBUS 250 ist mit einer PCI-Bus- Schnittstellenschaltung 255 verbunden, die mit dem PCI-Bus 105 verbunden ist. Der FBUS 250 ist ebenfalls mit einer Einrichtungsschnittstellenschaltung 252 verbunden (ebenfalls "Kunden-ASIC" genannt), die einen Schaltungsaufbau einschließt, um über eine Schnittstelle an den Video-D/A-Wandler 112 (Fig. 1), den Codec 114 und vielleicht an einen Video-A/D-Wandler (wie dies in den Fig. 4-6 dargestellt ist) anzukoppeln. Der Prozessor 110 schließt ebenfalls einen Speicherdatenübertrager 290 ein.

Der Prozessor 110 kann mehrere Datenströme gleichzeitig bearbeiten. Falls z. B. ein Nutzer des Prozessors 110 eine Videokonferenz mit zwei oder mehreren Teilnehmern führt, liefert der Prozessor 110 eine Video- und Audioverarbeitung, die es ermöglicht, daß der Nutzer mehrere Teilnehmer sieht und hört. Um mehrere Videodatenströme abzuwickeln, unterstützt der Prozessor 110 das Kontextschalten. Dies bedeutet, daß der BP 245 zwischen mehreren Datenströmen hin und her schaltet. Bei einer Videokonferenz kann jeder Datenstrom von einem separaten, entfernt gelegenen Teilnehmer kommen. Alternativ können zusätzliche Datenströme von Fernsehkanälen kommen, um dem Nutzer die Teilnahme an der Videokonferenz und das Schauen von einem oder mehreren Filmpräsentationen gleichzeitig zu ermöglichen. Das Kontextschalten ist im Anhang A, Abschnitt 10.12 beschrieben. Wenn Kontexte geschaltet werden sollen, speichert der Skalarprozessor 210 die aktuellen Kontexte und initialisiert den BP 245 einen anderen Kontext zu verarbeiten.

Der BP 245 kann die folgenden Videodatenformate bearbeiten:

1. MPEG-1, das im ISO/IEC-Standard 11172 (1992) beschrieben ist;
2. MPEG-2, das im Dokument ISO/IEC-JTC 1/SC 29 N 0981 Rev. (31. März 1995) beschrieben ist;
3. H.261, das in der "ITU-T-Recommendation H.261" (März 1993) beschrieben ist, und
4. H.263, das im "Draft ITU-T-Recommendation H.263" (2. Mai 1996) beschrieben ist.

Die Videodatenverarbeitung wird zwischen dem Skalarprozessor 210, dem Vektorprozessor 220 und dem Bitstrom-Prozessor 245 aufgeteilt, um eine hohe Verarbeitungsgeschwindigkeit zu erreichen. Insbesondere führt der Vektorprozessor 220 lineare Umformungen bzw. Transformationen (wie eine DCT (diskrete Cosinus- Transformation) oder ihr inverses, die IDCT) durch und führt eine Bewegungskompensation aus. Diese Operationen sind für einen Vektorprozessor geeignet, weil es diese Operationen häufig notwendig machen, daß der gleiche Befehl an mehreren Teilen der Daten ausgeführt wird. Der Bitstrom- Prozessor 245 führt ein Huffman-Codieren und -Decodieren und eine "Zick-Zack"-Bitstromverarbeitung durch. Der Skalarprozessor 210 führt ein Demultiplexen sowie ein Synchronisieren an Video- und Audiodaten durch und erledigt I/O-Schnittstellenaufgaben.

Beispiele für Codier- und Decodieroperationen befinden sich im Anhang A, Abschnitte 10.6.1 und 10.6.2. Bei einer Codieroperation kommen unkomprimierte, digitale Daten über den Bus 105 vom Speicher 120 oder vom Hauptsystem (nicht dargestellt). Bei einigen Ausführungsbeispielen schließt die Einrichtungsschnittstellenschaltung 252 einen Video- A/D-Wandler ein und die ent- bzw. dekomprimierten Daten kommen vom Wandler an. Der Vektorprozessor 220 führt eine Quantifizierung, die DCT und die Bewegungskompensation durch. Der Bitstrom-Prozessor 245 empfängt das Ausgangssignal vom VP 220 und erzeugt GOBs (Gruppen von Blöcken) oder Untergruppen bzw. Scheiben. Insbesondere führt der BP 245 Huffman- und RLC-Codierung und die "Zick- Zack"-Bitstromverarbeitung durch. Der Skalarprozessor 210 empfängt das Ausgangssignal des BP 245 und führt eine Bildschichten-Codierung, eine GOP-Codierung (eine Codierung von Gruppen von Bildern) und eine Zonenfolge-Codierung durch. Der Skalarprozessor 210 multiplext dann Audio- und Videodaten und überträgt die codierten Daten an eine Speichereinrichtung (über den Bus 105 oder 122) oder ein Netzwerk. Die Übertragung an ein Netzwerk schließt die Übertragung an die Einrichtungsschnittstellenschaltung 252 ein, die bei einigen Ausführungsbeispielen mit einem Netzwerk verbunden ist.

Beim Decodieren wird der Prozeß umgekehrt. Der Skalarprozessor 210 demultiplext die Systemdaten in Video- und Audioanteile und führt ein Zonenfolgen-Decodieren, ein GOP-Decodieren und ein Bildschichten-Decodieren von Videodaten durch. Die resultierenden GOBs oder die Untergruppen bzw. Scheiben werden an den Bitstrom-Prozessor 245 geliefert. Der Prozessor 245 führt eine "Zick-Zack"- Verarbeitung und eine Huffman- und RLC-Decodierung aus. Der VP 220 empfängt das Ausgangssignal des BP 245 und führt eine Dequantifizierung, eine IDCT und eine Bewegungskompensation aus. Der VP 220 führt jede Nachverarbeitung, die erforderlich sein könnte, aus (z. B. um die Kanten von Bildelementen zu glätten) und liefert rekonstruierte, digitale Bilder an die Einrichtungsschnittstellenschaltung 252 oder eine Speichereinrichtung. Der Skalarprozessor 210, der Vektorprozessor 220 und der Bitstrom-Prozessor 245 können parallel an verschiedenen Blöcken von Daten arbeiten.

Die Tatsache, daß der Skalarprozessor 210 die Bildschicht und höhere Schichten bearbeitet, verringert die Kommunikation zwischen den Prozessoren. Dies liegt daran, daß die Bildschicht und höhere Schichten Informationen enthalten, die vom Skalarprozessor 210 für Steuer- und I/O- Funktionen verwendet werden, die aber vom Vektorprozessor 220 oder Bitstrom-Prozessor 245 nicht verwendet werden. Ein Beispiel einer solchen Information ist die Geschwindigkeit der Datenübertragungsblöcke, die vom Skalarprozessor 210 zur Übertragung von Datenübertragungsblöcken an die Einrichtungsschnittstellenschaltung 252 verwendet wird.

Fig. 3 ist ein Blockdiagramm eines Ausführungsbeispiels des Bitstrom-Prozessors 245. Die in Fig. 3 dargestellten Signale werden im Anhang A, Abschnitt 10.5, beschrieben. Diese Signale liefern eine Schnittstelle zwischen dem Bitstrom-Prozessor 245 und dem IOBUS 240 (Fig. 2). Im BP 245 werden diese Signale durch die IOBUS-Schnittstellen- Einheit 310, die den SRAM 320 einschließt, abgewickelt. Der BP 245 schließt ebenfalls eine VLC-FIFO-Einheit 330, einen VLC-LUT-ROM 340, eine Steuerstatus- bzw. Steuerzustandsmaschine 350 und eine BP-Kerneinheit 360 ein, die ein Registerfile und einen SRAM einschließt. Die Blöcke von Fig. 3 werden im Anhang A, Abschnitt 10.4, beschrieben.

Der ROM 340 enthält Nachschlagetabellen (Look-up-Tabellen), die für das Huffman-Codieren und -Decodieren bei allen vier Standards - MPEG-1, MPEG-2, H.261 und H.263 - verwendet werden. Trotz der großen Menge von Informationen, die in den Tabellen gespeichert ist, weist der ROM 340 eine kleine Größe von 768×12 Bits auf. Die kleine Größe wird durch gemeinsame Verwendung der Tabellen und durch andere Techniken erreicht, die im Anhang B, Abschnitt 4, beschrieben sind.

Anhang A MSP-1EX Systembeschreibung Kapitel 1 - Technischer Überblick

Dieses Kapitel beschreibt den technischen Überblick des Mul timedia-Signalprozessors ("MSP-x"), wie er von den Hardware- und Software-Konstrukteuren gesehen wird.

1.1 Funktionalität

Die Multimedia-Signalprozessoren (MSP-x) bilden eine Familie von Einzelchip-VLSI-Einrichtungen, die konstruiert werden, um einen weiten Bereich der integrierten Funktionalität für Per sonal-Computer und Produktanwendungen von Verbrauchern vorzu sehen.

Die MSP-Familie basiert auf einer leistungsstarken Vektorpro zessor-Architektur, die ein Einzelbefehl-Mehrfachdaten- (SIMD-)Modell der Berechnung für optimale Kosten/Durchführung verwendet. Ihre Merkmale beinhalten:

- volle Programmierbarkeit
- auf der ARM Befehlsarchitektur basierend
- integrierter 40 MHz ARM7 RISC CPU Kern
- 80 MHz Vektorprozessor für digitale Hochleistungs-Signal verarbeitung
- 2,56 Gops für 9 Bit-Ganzzahl-ALU-Funktionen
- 2,56 Gops für 16 Bit-Ganzzahl-Multiplikationsakkumu lierungsfunktionen
- 640 Mflops für 32 Bit-IEEE-Gleitpunktaddition
- 1280 Mflops für 32 Bit-IEEE-Gleitpunktmultiplikation und -addition
- unbenutzte 10 Kgates für wahlweise Anpassung an Kunden wünsche oder graphische Funktionalität
- auf 0,65 um 3.3 V/5 V CMOS Technologie basierend
- 128-Pin bis 256-Pin-Gehäuse
Die MSP wird anfänglich 4 Hauptfunktionalitäten unterstützen:
- Video
- Ton/Akustik
- Telekommunikation
- 2D/3D Graphiken (wahlweise)

1.1.1 Video

- alle Funktionalitäten sind in Firmware programmierbar
- Realzeit MPEG-1-Decodierung und-Codierung
- Realzeit MPEG-2-Decodierung
- realzeitähnliche MPEG-2 Codierung
- Realzeit H.324-Decodierung und -Codierung
- Bildskalierung auf jede Bildschirmgröße oder Auflösung
- Umwandlung des Vektorraumes der Farbvalenzen zwischen RGB und YUV
- Bildfilterung für Bildvergrößerung und Rauschreduzierung
- 4/3 Abbrechumwandlung

1.1.2 Ton/Akustik

- alle Funktionalitäten sind in Firmware programmierbar
- Realzeit-MPEG-1-Audiodecodierung und -codierung
- Realzeit-MPEG-2-Audiodecodierung und -codierung
- Realzeit H.320 und H.324 Audiodecodierung und -codierung
- Realzeit G.728 und G.723 Sprachcodierung
- Realzeit-SoundBlaster-Emulation
- Wellentabellensynthese
- FM-Synthese

1.1.3 Telekommunikation 1.1.3.1 Modem

- Asynchrone Standard-COM-Anschlußschnittstelle (NS 16550A UART kompatibel)
- V.34 von 28.8 K bis 2.4 Kbps
- CCITT-V. 32 bis mit Übertragungsgeschwindigkeiten von Daten von 4800, 9600 uncodiert und 9600 bps trellisco diert
- Hayes-AT-Befehlssatz-Kompatibilität
- Ruffortschrittsmonitor
- V.25 bis Automatikwählen
- DTMF und Pulswählen
- Asynchrones Fehlerprotokoll
- V. 42 Fehlerkorrektur

1.1.3.2 Facsimile

- V.29 bei 9600 bps oder 7200 bps
- V.27ter bei 4800 bps oder 2400 bps
- Ruffortschrittsmonitor
- automatisches Wählen
- DTMF und Pulswählen
- G3 Übertragungen
- T.4/T.30 Funktionen

1.1.3.3 Telefonanrufbeantwortung

- Aufzeichnen von Grüßen über den Telefonapparat oder das Mikrophon
- automatisches Beantworten des Anrufes und Antworten mit vorher aufgezeichneter Nachricht
- Aufzeichnen einer Nachricht von dem Anrufer
- Abspielen der Nachrichten, die durch den Anrufer zurück gelassen werden

1.1.4 2D/3D Graphiken (wahlweise)

- BITBLT
- 2D Linien & polygone Zeichnungen und Schattierungen
- Geometrie & Beleuchtungsberechnung für 3D Punkte, Linien und Dreiecke
- 3D Farbberechnungen mit Strukturumsetzung
- Vermischen

1.2 Hardware-Architektur 1.2.1 Überblick

Die MSP-1-Multimedia-Coprozessor-Familie ist aufgebaut, um verschiedene Erfordernisse, die das Integrationsniveau, die Kosten und die Leistung einschließen, zu erfüllen. Ein Block diagramm eines Systems, das einen MSP-1-Prozessor beinhaltet, ist in Fig. 4 aufgezeigt.

Die MSP-1 Familie beinhaltet die folgenden Optionen:

- Der MSP-1 ist dafür konstruiert, als Eingangsniveau ohne externen SDRAM benutzt zu werden.
- Der MSP-1EX beinhaltet einen 32 Bit-Speicherbus zum Bil den einer Schnittstelle zu dem externen SDRAM.
- Der MSP-1F beinhaltet einen 64 Bit-Speicherbus zum Bil den einer Schnittstelle zu dem externen SDRAM.
- Der MSP-1G beinhaltet eine SVGA Steuerungseinheit, RAMDAC plus schnellerer 3D Graphikbeschleunigung.

Fig. 5 zeigt ein Blockdiagramm eines Systems, das einen MSP- 1E Prozessor beinhaltet.

1.2.2 Externe CODECs

Fig. 6 zeigt ein Blockdiagramm eines Systems, das einen MSP- 1-Prozessor mit externen Codecs beinhaltet.

1.2.2.1 MSP-1EX-Liste der Materialien

Nachfolgend ist eine vorgeschlagene Liste von Materialien für den MSP-1EX:

- MSP-1EX
- 512K×32-Bit synchroner DRAM
- NTSC/PAL-Codierer (KS0119 von SAMSUNG)
- Ton & Telekommunikations-Codec (AD1843 von ANALOG DEVICES)
- Gemischtes (Kondensatoren, Widerstände, Verstärker, Ver bindungsstücke, etc. . . .)
- Leiterplatte

1.3 MIKRO-Architektur 1.3.1 Überblick

Die MSP-Mikro-Architektur besteht grundsätzlich aus einem sehr leistungsstarken DSP-KERN und einem kundenspezifischen Speicher- & I/O-Untersystem. Siehe Fig. 2. Der DSP KERN bein haltet:

- eine 32-Bit ARM7 RISC CPU, die bei 40 MHz läuft und für allgemeine Verarbeitung benutzt wird;
- einen Vektorprozessor, der bei 80 MHz läuft und für Signalverarbeitung verwendet wird;
- ein gemeinsam genutztes Cache-Untersystem, welches bei 80 MHz läuft und 2 KB Befehlscache, 5 KB Datencache und
16 KB an ROM-Cache enthält. Der Datencache kann entweder durch die Hardware oder die Software gesteuert werden;
- ein schneller 64-Bit Bus (FBUS), der bei 80 MHz läuft und mit einer Anzahl von internen FBUS-Peripheriegeräten Schnittstellen bildet;
- ein langsamerer 32-Bit Bus (IOBUS), der bei 40 MHz läuft und Schnittstellen mit einer Anzahl von IOBUS- Peripheriegeräten bildet.

Die internen FBUS-Peripheriegeräte enthalten:

- eine 32-Bit 33 MHz PCI Bus-Schnittstelle;
- eine 64-Bit SDRAM Speichersteuerungseinheit;
- einen 8-Kanal DMA Steuereinheit;
- ein kundenspezifischer logischer ASIC-Block. Dieser ASIC-Block liefert 10 Kgates, die sowohl Schnittstellen zu verschiedenen analogen CODECs als auch kundenspezifi sche I/O-Vorrichtungen beinhalten. Die Schnittstellenlo gik unterstützt den KS0119-NTSC-Codierer von SAMSUNG und die AD1843-CODECs von ANALOG DEVICES;
- ein Speichendatenübertrager, welcher für DMA Daten von dem Hauptspeicher (Pentlure) zu dem lokalen MSP SDRAM- Speicher benutzt wird.

Die internen IOBUS-Peripheriegeräte beinhalten:

- einen Bitstrom-Prozessor, der für das Verarbeiten des Video-Bitstromes verantwortlich ist;
- eine 16450 serielle UART Leitung;
- eine 8254-kompatible Zeitsteuerung;
- eine 8259-kompatible Unterbrechungs-Steuerungseinheit;

Der MSP beinhaltet ebenfalls ein spezielles Register (MSP- Steuerungsregister), das für software-gesteuerte Initialisie rung und Unterbrechungen benutzt wird.

1.4 MSP-1EX Pin-Beschreibung 1.4.1 Insgesamt: 256 Pins (Stifte) 1.4.2 PC1 Bus-Schnittstelle (53 Pins)

CLK Takteingangspin
RSTL Rücksetzeingangspin, aktiv niedrig
AD [31 : 0] Adressen-und Datenbus-Pins
C_BE0L Steuerungs-und Byte 0 Einschaltpin, aktiv niedrig
C_BE1L Steuerungs-und Byte 1 Einschaltpin, aktiv niedrig
C_BE2L Steuerungs-und Byte 2 Einschaltpin, aktiv niedrig
C_BE3L Steuerungs-und Byte 3 Einschaltpin, aktiv niedrig
PAR Paritätspin
FRAMEL Zyklusrahmenpin, aktiv niedrig
IRDYL Initiatorfertigpin, aktiv niedrig
TRDYL Target-Fertigpin, aktiv niedrig
STOPL Stopp-Transaktionspin, aktiv niedrig
LOCKL Verriegelungstransaktionspin, aktiv niedrig
IDSEL Initialisierungsvorrichtungs-Auswahleingangspin
DEVSEL Vorrichtungsauswahlpin, aktiv niedrig
REQL Busanforderungspin, aktiv niedrig
GNTL Buserteilungspin, aktiv niedrig
PERRL Paritätsfehlerpin, aktiv niedrig
SERRL Systemfehlerpin, aktiv niedrig
INTAL Unterbrechungs-A-Pin, aktiv niedrig

1.4.3 Verschiedenes (6 Pins)

TCK JTAG Testtakteingangspin
TDI JTAG Testdateneingangspin
TDO JTAG Testdatenausgangspin
TMS JTAG Testmodusauswahleingangspin
TRSTL JTAG Testrücksetzungseingangspin
CLK Takteingang. Dies ist der 40 MHz-Takteingangspin.

1.4.4 KS0119 NTSC/PAL Codierungsschnittstelle (24 Pins)

SFRS Rahmensynchronisationsausgang zu KS0119 für 3- Leitungs-Hauptschnittstelle
SCLK Serieller Taktausgang zu KS0119
SDAT Serielle Daten I/O (Eingabe/Ausgabe)
BGHS Horizontales Synchronisationssignal, Eingang zu MSP
BGVS Vertikales Synchronisationssignal, Eingang zu MSP
MSSEL Hauptgeräteauswahl
PD [15 : 0] Pixeldatenausgang zu KS0119
BGCLK Pixeltaktausgang zu KS0119
PROMCSL BIOS PROM Chipauswahl

1.4.5 AD1843 Audio & Telekommunikations-CODEC-Schnittstelle (6 Pins)

A43SCLK Serieller Takt, Eingang/Ausgang. SCLK ist ein zwei gerichtetes Signal, das den Takt als einen Ausgang an den seriellen Bus liefert, wenn der Bus Master (BM)-Pin auf HI betrieben wird und den Takt als ei nen Eingang akzeptiert, wenn der BM-Pin auf LO an getrieben wird.
A43SDFS Serielle Datenrahmensynchronisation, Ein gang/Ausgang. SDFS ist ein zweigerichtetes Signal, das das Rahmensynchronisationssignal als einen Aus gang an den seriellen Bus liefert, wenn der Bus Ma ster (BM)-Pin auf HI betrieben wird und das Rahmen synchronisationssignal als einen Eingang akzep tiert, wenn der BM-Pin auf LO angetrieben wird.
A43SDI Serieller Dateneingang an den AD 1843, Ausgang vom MSP. Alle Steuerungs-und Wiedergabeübertragungen sind 16 Bit lang, zuerst das MSB.
A43SDO Serieller Datenausgang vom AD 1843, Eingang zu MSP. Alle Status- und Steuerungsregisterlese- und -wiedergabeübertragungen sind 16 Bit lang, zuerst MSB.

1.4.6 Speicherbusschnittstelle (87 Pins)

RAS1L Ausgabepin (aktiv niedrig). Dies sind Zeilenadres senabtastimpulse, um die Zeilenadressen vom MA [11 : 0] in dem internen Zeilenadressenpuffer der ausgewählten SDRAM-Bank zu speichern.
CAS1L Ausgangspin (aktiv niedrig). Dies sind Spaltena dressenabtastimpulse, um die Spaltenadressen vom MA [11 : 0] in dem internen Spaltenadressenpuffer der ausgewählten SDRAM-Bank zu speichern.
MWEL Ausgangspin (aktiv niedrig). Dies ist die Schreib freigabe zu dem SDRAM.
MAI [11 : 0] Ausgangpins. Multiplexierte Zeilen-und Spal ten-Adressensignale zu dem SDRAM.
MD [63 : 0] Eingangs-/Ausgangs-SDRAM Datenpins.
MA23 Ausgangspin. Speicheradressenbit (

23

)
MA24 Ausgangspin. Speicheradressenbit (

24

)
DQM Ausgangspin. Stellt die SDRAM Datenausgangshochim pedanz nach dem Takt her und maskiert den Ausgang. (Dieser Pin wird nur für synchrone DRAM-Schnitt stellen benutzt).
MCKE Ausgangspin. Maskiert den Systemtakt des SDRAM, um die Funktion von dem nächsten Taktzyklus einzufrie ren.
MCSOL Ausgangspin (aktiv niedrig). SDRAM-Chipauswahl für die niedrigen 32 Bit.
MCSIL Ausgangspin (aktiv niedrig). SDRAM-Chipauswahl für die hohen 32 Bit.
MR.DYH Ausgangspin. SDRAM-Bereitsignal.
MEMCLK Ausgangspin. Dies ist der Taktausgangspin zu dem SDRAM.

1.4.7 Stromversorgungen

VDD 3.3 Volt-Stromversorgungspins
VCC 5 Volt Stromversorgungspins
VSS Erdungspins

MSP-1EX Pinzuordnung

In der Spalte "Typ" bedeuten IN = Eingang, OUT = Ausgang und I/O = Eingang/Ausgang.

1.5 Firmware Architektur 1.5.1 Überblick

Der MSP liefert viel von seinen leistungsstarken für Anwen dungen offenen Betriebsarten durch eine höchstoptimierte Kom bination von vektorisierten DSP-Firmwarebibliotheken (durch den Vektorprozessor ausgeführt) und System- Managementfunktionen (durch ARM7 ausgeführt).

Der MSP trennt die Signalverarbeitungsentwicklung von der Da tenanbieteranwendungsentwicklung, wodurch er skalierbare Durchführung, kosteneffektive Multimedia & Kommunikation und leichte Benutzung und Handhabbarkeit vorsehen kann. Ebenso wird er die Anwendungsentwicklung und die Wartungskosten re duzieren.

1.5.2 Firmware-Architektur

Die MSP Firmware-Systemarchitektur wird in der Fig. 7 darge stellt. Die schattierten Gebiete stellen die MSP Systemkompo nenten dar. Die weißen Gebiete sind die residenten PC-An wendungen und Betriebssystem.

1.5.2.1 MOSA (Multimedia Betriebssystem-Architektur)

Der MSP-Realzeit-Betriebssystemkern wird "MOSA" genannt, wel cher ein Teilsystem des Microsoft Realzeitkernes MMOSA ist.

MOSA ist ein realzeitliches, robustes, Mehrprozeßbetrieb er möglichendes, präemptives Betriebssystem, das für Multimedia- Anwendungen, die auf dem MSP implementiert werden, optimiert ist. Es wird die folgenden Hauptfunktionen durchführen:

- Schnittstelle-Bilden zu dem Hauptrechner Windows 95 & Windows NT
- Herabladen von ausgewählter Anwendungs-Firmware von dem Hauptrechner
- Steuerung von MSP Tasks zum Ausführen in der ARM7 und dem Vektorprozessor
- Management von allen MSP Systemelementen einschließlich dem Speicher & I/O-Vorrichtungen
- Synchronisation von der Kommunikation zwischen MSP Tasks
- Berichten von MSP-bezogenen Unterbrechungs-, Ausnahme- und Statuszuständen

MOSA läuft exklusiv auf der ARM7.

Bitte beziehen sie sich auf die MMOSA Realzeitkernbeschrei bung für nähere Details.

1.5.2.2 Multimedia-Bibliotheksmodul

Das Multimedia-Bibliotheksmodul sieht einen Platinenbereich von Modulen vor, der Funktionen wie Datenkommunikation, MPEG Video & Ton, Sprachcodierung und Synthese, SoundBlaster kompatibler Ton, etc. durchführt. Jedes Modul wird für die MSP-Umgebung optimiert und wird konstruiert, um in einer Mehrprozeßbetriebsumgebung abzulaufen.

1.5.3 Telecom-Bibliothek 1.5.3.1 Überblick

Mit der passenden DSP-Firmware kann der MSP benutzt werden, um Sprachanwendungen mit Einfangen, Antworten auf eingehende Telefonanrufe und Speichern von Nachrichten auf Plattenspei cher zu unterstützen. Der Systemlautsprecher kann ebenfalls mit einem Mikrofon benutzt werden, um den Service eines halb duplexen Lauthörtelefones vorzusehen, ohne den Telefon- Handapparat zu benutzen. Der Fortschritt der einkommenden und ausgehenden Anrufe wird detektiert und durch das System be nutzt. Anruffortschrittöne können ebenso durch den Telefon- Handapparat, den Systemlautsprecher, Stereo-Kopfhörer oder Tonausgangskanälen, wie sie unter der Programmsteuerung aus gewählt werden, gehört werden.

1.6 Programmiermodell 1.6.1 Überblick

Von dem Standpunkt einer Hardware ist der MSP eine Einzel- Chiplösung, die zwei CPUs und eine Anzahl von integrierten peripheren Vorrichtungen enthält. Vom Standpunkt einer Soft ware ist der MSP eine hochleistungsfähige digitale Signalver arbeitungs-(DSP-)Vorrichtung, die sich auf dem PCI-Bus befin det.

Die Steuerung des MSP durch die Haupt-CPU wird erreicht durch entweder:

- Lesen und Schreiben der MSP-Steuerungs- und Statusregister durch den PCI-Bus oder
- gemeinsam benutzte Datenstruktur, die in dem Hauptrech nersystemspeicher geladen ist,
- gemeinsam benutzte Datenstruktur, die in dem lokalen MSP Speicher geladen ist.

Die MSP-Programmausführung beginnt immer mit der ARM7 CPU, welche wiederum einen zweiten unabhängigen Ausführungsstrom in dem Vektorprozessor initiieren kann. Die Steuerungssyn chronisation zwischen der ARM7 CPU und dem Vektorprozessor kann durch bestimmte Coprozessor-Befehle in der ARM7 (STARTVP, INTVP, TESTVP) und spezifische Befehle in dem Vek torprozessor (VJOIN und VINT) durchgeführt werden. Die Daten übertragung zwischen der ARM7 und dem Vektorprozessor kann durch Datenbewegungsbefehle durchgeführt werden, die in der ARM7 ausgeführt werden.

Die ARM7 CPU ist typischerweise für die Hauptrechnerschnitt stelle, das Betriebsmittel-Management, die I/O-Vorrichtungs- Handhabung als auch für die meisten Unterbrechungs- und Ausnah meverarbeitungen verantwortlich. Der Vektorprozessor ist für die gesamte digitale Signalverarbeitung und bestimmte spezi elle Unterbrechungen, wie der Coprozessorunterbrechung (aus gegeben durch die ARM7 an den Vektorprozessor) oder den Hard ware-Stapelüberlauf (in dem Vektorprozessor) verantwortlich.

Der MSP beinhaltet ebenfalls eine Anzahl von integrierten Pe ripheriegeräten zum Schnittstellen-Bilden zu verschiedenen I/O-Vorrichtungen. Alle Peripherievorrichtungsadressen sind speicherzugeordnet, und deshalb kann auf sie mit Standard- Speicherlade- und Speicherbefehlen (durch entweder der ARM7 CPU oder dem Vektorprozessor) zugegriffen werden.

1.6.2 Einschalten, Zurücksetzen und Initialisierung

Nach dem Einschalten wird der MSP automatisch in eine Selbst testsequenz eintreten, um komplett seine Funktionalität zu verifizieren. Die Selbsttestsequenz beinhaltet:

- Initialisierung von allen internen MSP-Registern
- Ausführung der auf dem Chip befindlichen Selbsttestdia gnostiken, um alle Komponenten des MSP zu verifizieren, und es wird erwartet, daß es etwa <tbd< Sekunden dauert. Am Ende der Selbsttestsequenz wird der MSP bereit sein, die MSP- Firmware auszuführen, welche beinhalten wird:
- Laden und Ausführen der MSP Initialisierungssoftware
- Laden und Ausführen des MSP Realzeit-Betriebssystemkerns MMOSA.

Der MSP unterstützt drei Arten von Zurücksetzen:

- Hardware-gesteuertes Systemrücksetzen durch den PCI-Bus
- Software-gesteuertes Systemrücksetzen durch das PCI-System.
Setzt das Bit in dem MSP-Steuerungsregister zurück.
- Software-gesteuertes Wiederstarten durch den ARM7 und Vek torwiederstartbit, das ebenso in dem MSP-Steuerungsregi ster vorliegt.

1.6.3 PCI-Konfigurationsregister

Als eine I/O-(Eingabe/Ausgabe)-Einrichtung auf dem PCI-Bus enthält der MSP einen Satz von Konfigurationsregistern, wie dies durch die PCI-Revision 2.1-Spezifikation be stimmt und in Tabelle 2 verdeutlicht ist.

PCI-Konfigurationsregister

1.6.3.1 Vorrichtungs- und Lieferanten-Identifizierungsregister

Bitte beziehen sie sich auf die PCI-Busbeschreibung Rev 2.1 für nähere Details.

1.6.3.2 Status- und Befehlsregister

1.6.3.3 Klassencode- und Revision-Identifizierungsregister

Für den MSP-1EX wird der Klassencode als 03 seiend definiert, und die Unterklasse ist 0.

1.6.3.4 Zusatzregister

1.6.3.5 MSP-Basisadressenregister (MSP_BASE)

Dieses Register enthält die Basisadresse für die MSP- Vorrichtung. Sie wird durch die Hauptrechnersystem-Software (Windows 95/NT) eingeschrieben und wird durch die MSP- Hardware für Speicheradressierung benutzt.

1.6.3.6 VFB-Basisadressenregister

Dieses Register enthält die Basisadresse für den virtuellen VGA Rahmenpuffer. Er wird durch die Hauptrechnersystem- Software (Windows 95/NT) eingeschrieben und wird durch die MSP-Hardware für die Emulation der VGA-Rahmenpuffer benutzt.

1.6.3.7 Erweiterungs-ROM-Basisadresse

1.6.3.8 Unterbrechungsleitungsregister

1.6.4 ARM7 CPU

Die ARM7 RISC CPU ist der Hauptprozessor des MSP. Er enthält 32-Bit-Datenwege und stimmt mit der Standard-ARM7- Befehlssatz-Architektur überein. Die ARM7 beinhaltet eben falls spezielle Coprozessor-Befehle, um mit dem Vektorprozes sor gekoppelt zu werden.

1.6.5 Vektorprozessor

Der Vektorprozessor ist der DSP-Prozessor des MSP. Er enthält 288 Bit-Datenwege und funktioniert als ein Coprozessor zu der ARM7. Seine Funktionalität ist wie in dem Vektorprozessor- Architekturdokument beschrieben.

Der Vektorprozessor läuft mit 80 MHz und enthält 6 Pipeli nestufen: abrufen, decodieren, ausgeben, auf Register zugrei fen, ausführen und schreiben. Dies wird für DSP-bezogene Ver arbeitung optimiert.

1.6.6 Virtuelles Speichermanagement

Der MSP-1EX unterstützt NICHT das virtuelle Speichermanage ment.

1.6.7 Unterbrechungs- und Ausnahmeverarbeitung

Die Unterbrechungs- und Ausnahmeverarbeitung in dem MSP wird meistens durch die ARM7 durchgeführt.

Alle internen Eingangs-/Ausgangsvorrichtungsunterbrechungen gehen in die interne 8254 Unterbrechungs- Steuerungseinrichtung, welche sie prioretisiert, und sendet die Unterbrechung mit höchster Priorität zur ARM7 für die weitere Verarbeitung.

1.6.8 Physikalische Speicheradressenzuordnung

Die ARM7 und die Vektorprozessorprogramme betrachten alle MSP Eingangs-/Ausgangsvorrichtungen als speicherzugeordnet ent sprechend dem physikalischen Speicher, wie in Fig. 8 unten dargestellt.

Bitte bemerken sie, daß die MSP-Adressenzuordnung, wie durch die ARM7 (oder dem Vektorprozessor) gesehen, von Null startet und sich über den gesamten Weg hinauf bis 4 GB erstreckt.

In dem Bereich von 2 GB bis 4 GB werden die Adressen den Hauptrechner-(Pentium)-PCI-Adressen von 0 bis 2 GB entspre chend der folgenden Beziehung zugeordnet:
Hauptrechner PCI Adresse: = ARM7 Adresse-8000 0000 (in hex).

Diese Zuordnung ermöglicht der ARM7 (oder dem Vektorprozes sor), Adressen zu benutzen, die von 2 GB bis 4 GB reichen, um auf Hauptrechner-PCI-Speicheradressen zuzugreifen, die von 0 bis 2 GB reichen. Auf alle Hauptrechner-PCI-Speicheradressen jenseits der 2 GB kann die ARM7 nicht zugreifen.

Die Hauptrechner-(Pentium-)Programme betrachten ebenso alle MSP-Eingangs/Ausgangsvorrichtungen als speicherzugeordnet, jedoch entsprechend einer begrenzteren physikalischen Adres senzuordnung, wie in Fig. 9 dargestellt.

Bitte bemerken sie, daß aus der Sicht von den Hauptrechner- (Pentium-) Programmen:

- MSP_BASE der Start der MSP-Adressenzuordnung ist;
- MSP_BASE + 7DFFFFF das Ende der MSP-Adressenzuordnung ist;
- die MSP-Adressenzuordnung nur in diesem Bereich von 128 MB definiert wird.

MSP I/O Vorrichtungsadressenzuordnung

1.6.9 MSP-Hauptrechner-Steuerungsregister

Der MSP-1EX enthält ein spezielles Register, welches für Initialisierung und Unterbrechungen durch den Hautrechner (Pentium-Prozessor) benutzt wird.

MSP Hauptrechner-Steuerungsregister-Definition

Bit <0< PCI-Systemrücksetzung. Dieses Bit wird durch den Hauptrechner (Pentium) benutzt, um die gesamte MSP Systemhardware einschließlich aller MSP-verwandten internen & externen Eingangs/Ausgangsvorrichtungen komplett zurückzusetzen. Nach einem PCI System- Zurücksetzen wird der MSP seine Standardrückset zungsseguenz einschließlich dem Ausführen von allen auf dem Chip befindlichen Selbsttestdiagnostiken für ARM7, dem Vektorprozessor und den I/O- Vorrichtungen durchlaufen. Dieses Zurücksetzen hat die gleiche Wirkung wie das Hardwaresystem- Zurücksetzen.

Bit <1< ARM7 & Vektorprozessor-Wiederstart. Dieses Bit wird durch den Hauptrechner (Pentium) benutzt, um sowohl die ARM7 als auch den Vektorprozessor wieder zu starten. Dieser Wiederstart ist zu dem kompletten PCI-System-Zurücksetzen in dem Sinne verschieden, daß der MSP nicht jede von seinen normalen Zurück setzsequenzen durchläuft und nicht jede der auf dem Chip befindlichen Selbsttestdiagnostiken durch führt. Wenn dieses Bit gesetzt wird, wird die ARM7 die Ausführung bei der Adresse 0 starten und der Vektorprozessor wird in den Leerlaufmodus eintre ten. Keine internen oder externen I/O-Vorrichtungen werden betroffen sein.

Bit <2< MSP Unterbrechungsanfrage vom Hauptrechner (Penti um). Dieses Bit wird von dem Hauptrechner (Pentium) zur direkten Unterbrechung des MSP benutzt und es wird mit einem der Eingänge der internen program mierbaren Unterbrechungssteuerungseinrichtung 8259 (PIC) verbunden, welche wiederum benutzt wird, um die ARM7 zu unterbrechen. Dieses Bit wird durch den Hauptrechner (Pentium) gesetzt und von der ARM7 ge löscht.

Bit <3< PCI Hauptrechner-Unterbrechungsbestätigung. Dieses Bit wird durch den Hauptrechner (Pentium) zur Be stätigung der PCI Hauptrechner- Unterbrechungsanfrage, die durch den MSP erzeugt wird, benutzt. Dieses Bit wird durch den Hauptrech ner (Pentium) gesetzt und durch den ARM7 gelöscht.

Bit <31 : 4< Reserviert.

1.6.10 MSP ARM7 Steuerungsregister

Der MSP-1EX enthält ein Spezialregister, welches für die Un terbrechung des Hauptrechners durch den ARM7 Prozessor be nutzt wird.

MSP ARM7 Steuerungsregisterdefinition

Bit <0< PCI Hauptrechnerunterbrechung vom MSP. Dieses Bit wird benutzt von dem MSP, um den Hauptrechner durch Aktivierung des PCI INTA# Pin auf dem PCI Bus zu unterbrechen. Dieses Bit wird durch die ARM7 ge setzt und wird durch den Hauptrechner (Pentium) über den PCI Bus gelöscht.

Bit <31 : 1< Reserviert

1.6.11 Internes MSP uROM

Das interne ROM enthält insgesamt 16 KBytes und beinhaltet:

- uROM Initialisierungssoftware
- Selbsttestdiagnostik-Software
- verschiedene Systemmanagement-Software
- verschiedene Bibliotheks-Subroutinen
- Cache für bestimmte Befehle und Datenkonstanten

Seine Adressenzuordnung wird in Tabelle 6 unten dargestellt.

Interne uROM Adressenzuordnung

1.6.12 Interner MSP SRAM

Der interne SRAM kann entweder als ein Cache oder lokaler Speicher abhängig von der Auswahl, wie durch das MSP Vektor- und Steuerungs- und Statusregister (VCSR) spezifiziert wird, funk tionieren.

Im lokalen Speichermodus wird sein Adressenraum auf den in ternen SRAM Abschnitt abgebildet, beginnend an der Stelle <MCP_BASE<: 040 0000.

1.6.13 Interne MSP-Peripheriegeräte

Der MSP enthält ebenfalls eine Anzahl von Peripheriegeräten, die sich auf seinen 2 internen Bussen befinden: 64 Bit, 80 MHz Fbus und 32 Bit, 40 MHz IO Bus.

Die Vorrichtungen auf dem Fbus beinhalten:

- Speicherungssteuerungseinheit für externen synchronen DRAM
- eine virtuelle Rahmenpufferschnittstelle
- eine PCI Bus-Steuerungseinheit für externen PCI Bus
- Kunden ASIC Schnittstelle
- eine 8-Kanal DMA Steuerungseinheit
- einen Speicherdatenübertrager (für Datenübertragung zwi schen Hauptrechnerspeicher und SDRAM
- Serielle KS0122 CODEC Leitung
- Serielle KS0119 CODEC Leitung
- Serielle AD1843 CODEC Leitung

Die Vorrichtungen auf dem IObus beinhalten:

- eine 8254-kompatible programmierbare Intervallzeitsteue rung
- eine 8259-kompatible programmierbare Unterbrechungs- Steuerungseinrichtung (8 Niveaus)
- eine 16450-kompatible UART serielle Leitung
- einen Bitstromprozessor für das MPEG Video-Bitstromde codieren und -codieren

Die Registeradressenzuordnung von diesen Peripheriegeräten wird in Tabelle 7 dargestellt.

TABELLE 7

Interne Peripherieregister-Adressenzuordnung

1.6.14 IOBUS Peripheriegeräte 1.6.14.1 8254-kompatible programmierbare Intervallzeitsteue rung

Der MSP beinhaltet eine 8254-kompatible programmierbare Stan dard-Intervallzeitsteuerung zum Gebrauch durch die Software mit der folgenden Funktionalität:

- enthält 3 unabhängige 16-Bit Zähler
- unterstützt 6 programmierbare Zählermoden

Alle Zähler werden durch Schreiben in das Steuerungswortregi ster und den Anfangszähler programmiert.

Steuerungswortregister

Dieses Register enthält verschiedene Steuerinformation für die Zeitsteuerung. Seine Bitdefinition wird in Tabelle 8 un ten beschrieben.

Steuerungswortregister

Statusregister

Dieses Register enthält Statusinformationen der Zeitsteue rung.

Zähler 0, 1 und 2

Diese 3 Register sind die Hauptzählelemente der Zeitsteue rung. Jeder Zähler ist 16-Bit breit, voreinstellbar ist zählt in jedem binären BCD Modus abwärts. Sein Eingang, seine Tor schaltung und der Ausgang werden durch die Auswahl des MODES konfiguriert, der in dem Steuerungswortregister gespeichert ist. Die 3 Zähler sind vollständig unabhängig.

1.6.14.2 8259-kompatible programmierbare Unterbrechungs steuerungseinheit (PIc)

Die programmierbare MSP-Unterbrechungssteuerungseinheit ist der Standard 8259, der in allen x86-basierenden Personal-Com putern üblich ist. Seine Funktionalität beinhaltet:

- unterstützt 8 Prioritätsniveaus
- programmierbare Unterbrechungsmoden
- individuelle Anfragemaskierungsfähigkeit

In dem MSP-1EX werden die 8 Niveaus der Unterbrechungseingän ge versuchsweise zu verschiedenen ldO Vorrichtungen wie folgt zugewiesen:

- Niveau 0 (am höchsten) wird der 8254 Zeitsteuerung zuge wiesen,
- Niveau I wird dem virtuellen Rahmenpuffer (VFB) zugewie sen,
- Niveau 2 wird dem logischen Kunden-ASIC-Block ein schließlich der DMA-Steuerungseinheit zugewiesen,
- Niveau 3 wird dem Bitstromprozessor zugewiesen,
- Niveau 4 wird der PCI Busschnittstelle zugewiesen,
- Niveau 5 wird <tbd< zugewiesen,
- Niveau 6 wird <tbd< zugewiesen,
- Niveau 7 wird dem 16550 UART zugewiesen.

Das Ausgangssignal der Unterbrechungssteuerungseinheit wird mit der Unterbrechungsanfrageleitung (nFIQ) der ARM7 RISC CPU verbunden.

Registerbeschreibung

Es gibt drei 8-Bit Register, welche benutzt werden, um den Betrieb der PIC zu initialisieren:

- Initialisierungsbefehlswort 1 (ICW1)
- Initialisierungsbefehlswort 2 (ICW2): nicht im MSP-1EX benutzt
- Initialisierungsbefehlswort 3 (ICW3): nicht im MSP-1EX benutzt
- Initialisierungsbefehlswort 4 (ICW4)

Es gibt andere drei 8-Bit Register, welche benutzt werden, um den Betrieb der PIC zu steuern:

- Betriebssteuerungswort 1 (OCW1)
- Betriebssteuerungswort 2 (OCW2)
- Betriebssteuerungswort 3 (OCW3)

Bitte bemerken sie, daß das Adressieren von all diesen Regi stern sowohl in dem Adressenanteil (Bit <0<) als auch in dem Datenanteil speziell codiert wird. Bitte beziehen sie sich auf die 8259 Standard Beschreibung für nähere Details.

Tabelle 9

8259 Registerbeschreibung

1.6.14.3 Serielle 16450-kompatible UART Leitung

Der MSP beinhaltet eine serielle 16450-kompatible UART Lei tung, welche als eine Schnittstelle zu den externen seriellen I/O(Eingabe/Ausgabe)-Vorrichtungen benutzt wird.

Bitte beziehen sie sich auf die 16450 Standard Beschreibung für nähere Details.

1.6.14.4 Bitstromprozessor

Der Bitstromprozessor ist ein spezialisierter logischer Block, welcher Videobitstromdaten verarbeitet. Seine Funktio nalität beinhaltet:

- HUFFMAN-Decodierung und -Codierung mit veränderlicher Länge;
- Entpacken und Verpacken von Videodaten in einem ZICKZACK-Speicherformat;
- andere Zusatzbitniveau-Verarbeitung.

Der Bitstromprozessor arbeitet als eine Simultanverarbei tungseinheit und steht unter Softwaresteuerung entweder durch den Vektorprozessor oder die ARM7. Für nähere Details bezie hen sie sich bitte auf das Bitstromprozessor-Kapitel.

1.6.15 FBUS Peripherigeräte

Die FBUS Peripheriegeräte beinhalten:

- Logische Kunden ASIC Schnittstelle
- eine 8-Kanal DMA Steuerungseinheit
- serielle Videocodier-Leitungsschnittstelle zu SAMSUNG's KS0119
- serielle Ton und Telekommunikations-Leitungsschnittstelle zu ANALOG DEVICES's AD1843

1.6.15.1 Schnittstelle mit ASIC Schnittstellen-Logik

Dieser Abschnitt enthält die Schnittstellenlogik zu allen ex ternen CODECs und den kundenspezifischen logischen ASIC Blocks. Dieser Block wird komplett in der Hardware implemen tiert, und es gibt kein programm-sichtbares Register. Bitte beziehen sie sich auf das ASIC Schnittstellenkapitel für nä here Aufbaudetails.

1.6.15.2 DMA Steuerungseinheit

Der MSP-1EX enthält eine auf dem Chip befindliche DMA Steue rungseinheit mit folgender Funktionalität:

- 8 unabhängige DMA Kanäle;
- Einschalt/Abschaltsteuerung der individuellen DMA Kanä le;
- Übertragungen von I/O-Vorrichtung zum Speicher oder umge kehrt;
- Adressenzu- und -abnahme.

Bitte beziehen sie sich auf das ASIC Schnittstellenkapitel für nähere Aufbaudetails.

1.6.15.3 Speicherdatenübertrager

Der MSP-1EX enthält ebenfalls andere spezielle Speicherda tenübertrager, welche für das Übertragen bzw. Bewegen von Da ten zwischen dem Hauptrechner-(Pentium-)Speicher und dem lo kalen MSP SDRAM Speicher benutzt wird. Der Speicherdatenüber trager ist grundsätzlich eine spezielle DMA Steuerungsein heit, die die folgenden Register enthält:

- Aktuelles MSP Adressenregister: Dieses 32-Bit Register definiert die SDRAM Speicheradresse bei dem Beginn der Speicherdatenübertragung. Dieses Register kann durch die ARM7 gelesen oder geschrieben werden, und der anfängli che Wert sollte durch die ARM7 geladen werden. Die Adresse wird basierend auf der Datenübertragungsgröße erhöht.
- Aktuelles Hauptrechner-Adressenregister: Dieses 32-Bit Register definiert die Hauptrechner-Speicheradresse zu Beginn der Speicherdatenübertragung. Dieses Register kann durch die ARM7 gelesen oder geschrieben werden und der Anfangswert sollte durch die ARM7 geladen werden. Die Adresse wird basierend auf der Datenübertragungsgrö ße erhöht.
- MSP Stopp-Adressenregister: Dieses 32-Bit Register defi niert die SDRAM Speicheradresse an dem Ende der Spei cherdatenübertragung. Dieses Register kann durch die ARM7 gelesen oder geschrieben werden und wird benutzt, um mit dem aktuellen MSP Adressenregister verglichen zu werden. Wenn es eine Übereinsstimmung gibt, so wird der Speicherdatenübertrager ein Hauptrechner- Prozeßendesignal erzeugen.
- Hauptrechner-Stopp-Adressenregister: dieses 32-Bit Regi ster definiert die Hauptrechner-Speicheradresse an dem Ende der Speicherdaten-Übertragung. Diese Register kann durch die ARM7 gelesen oder geschrieben werden und wird benutzt werden, um mit dem aktuellen Hauptrechner- Adressenregister verglichen zu werden. Wenn es eine Übereinsstimmung gibt, so wird der Speicherdatenübertra ger ein Hauptrechner-Prozeßendesignal erzeugen.
- Statusregister: Dieses Register enthält Statusinformati on, die sich auf den Datenübertrager bezieht. Die Bitco dierung ergibt sich wie folgt:
<0<: MSP EOP. Dieses Bit beschreibt, ob der Speicherda tenübertrager die MSP Stopp-Adresse erreicht hat oder nicht. Es wird auf 0080 000 (hex) zurückge setzt, wenn die ARM7 das aktuelle Quellen- Adressenregister initialisiert. Dieses Bit sollte nur gelesen werden und NICHT durch die ARM7 ge schrieben werden.
<1<: Hauptrechner EOP. Dieses Bit beschreibt, ob der Speicherdatenübertrager die Hauptrechner- Stoppadresse erreicht hat oder nicht. Es wird auf 8000 000 (hex) zurückgesetzt, wenn die ARM7 das ak tuelle Hauptrechner-Adressenregister initialisiert. Dieses Bit sollte nur gelesen werden und NICHT durch die ARM7 geschrieben werden.
- Steuerungsregister: Dieses Register enthält Informatio nen, die sich auf den Speicherdatenübertrager beziehen. Die Bitcodierung wird wie folgt sein:
<0<: Richtung. Dieses Bit beschreibt die Richtung der Datenübertragung. Wenn es eine "0" ist (Standard), so wird die Richtung der Datenübertragung von dem Hauptrechner-(Pentium-)Speicher zu dem MSP SDRAM Speicher sein. Wenn es ein "1" ist, so wird die Richtung von dem SDRAM zu dem Hauptrechnerspeicher sein. Dieses Bit soll durch die ARM7 geschrieben werden.
<1<: Unterbrechungseinschaltung bzw. -freigabe. Dieses Bit beschreibt, ob der Speicherdatenübertrager die ARM7 an dem Ende der Datenübertragung unterbrechen sollte oder nicht. Dieses Bit sollte durch die ARM7 geschrieben werden.
<2<: DMA Endschaltung. Dieses Bit schaltet den Speicher datenübertrager zum Betrieb ein. Dieses Bit sollte durch die ARM7 geschrieben werden.
<3<: Datenübertragungsgröße. Wenn es eine "0" ist (Stan dard), so wird die Größe von jeder Speicherdaten übertragung 32 Bytes sein. Wenn es eine "1" ist, so wird die Größe 64 Bytes sein. Dieses Bit sollte durch die ARM7 geschrieben werden.

1.6.15.4 Serielle KS0119 Videocodier-Leitungsschnittstelle

Die serielle KS0119 Videocodier-Leitungsschnittstelle bein haltet:

- ein Doppelpuffer-Empfangsdatenpufferregister, welches diese Daten von dem CODEC enthält,
- ein Doppelpuffer-Sendedatenpufferregister, welches Schreibdaten an den CODEC enthält,
- ein Steuerungs- und Statusregister, welches verschiedene Steuerungs- und Zeichenstatusinformationen für die seri elle Leitung enthält.
Tabelle 10

Serielle KS0119 Videocodier-Leitungsschnittstellenregister

Die Bitcodierung des Steuerungs- & Statusregisters ist wie folgt:

Bit <0< Empfangsdatenpuffer ist voll. Dieses Bit wird ge setzt, wenn die serielle Leitung 8 Bits an Daten von dem KS0119 CODEC empfangen hat. Wenn die Unter brechungseinschaltung (Bit <7<) gesetzt ist, wird eine Unterbrechungsanfrage ebenso an die ARM7 aus gegeben.

Bit <1< Sendedatenpuffer ist leer. Dieses Bit wird gesetzt, wenn die serielle Leitung bereit ist, Daten an den KS0119 CODEC zu senden. Wenn die Unterbrechungsein schaltung (Bit <7<) gesetzt wird, so wird ebenso eine Unterbrechungsanfrage an die ARM7 ausgegeben.

Bit <7< Unterbrechungseinschaltung bzw. -freigabe. Dieses Bit wird benutzt, um die Unterbrechungsanfrage an die ARM7 einzuschalten.

1.6.15.5 Serielle AD1843 Ton und Telekom Leitungsschnittstelle

Die serielle AD1843 Leitungsschnittstelle beinhaltet:

- einen Satz an doppelgepufferten Registern, welche Lese daten von dem CODEC enthalten,
- einen Satz an doppelgepufferten Registern, welche Schreibdaten an den CODEC enthalten,
- ein Steuerungs- und Statusregister, welches verschiedene Steuerungs- und Statusinformationen für die serielle Lei tung enthält.

Bitte beziehen sie sich auf das AD 1843 CODEC Schnittstellen kapitel für nähere Details.

1.6.16 Befehls-Leistungsfähigkeit

Tabelle 11 zeigt eine Befehlsdurchführung im Vektorprozessor zykluszählen, wo jeder Zyklus gleich 12,5 ns ist. Die externe Speicherbusbreite wird mit 64 Bit mit einem Seiten modustakt von 40 MHz angenommen. Alle Befehlsdurchführungen werden in dem 32-Byte Vektormodus gegeben. Die Konvention ist wie folgt:

ras: Anzahl der Zyklen, die durch externe Speicher für den ersten Zugriff erforderlich sind. Sie ist typischerweise gleich 75 ns oder 6 Zyklen.

Latenzzeit: Anzahl der Zyklen zum Ausführen des ersten Be fehls.

Rate: Anzahl der Zyklen zwischen der Ausführung von ähnlichen sequentiellen Befehlen.

Wenn die Latenzzeit dieselbe wie die Rate ist, wird nur eine Zahl gezeigt.

Befehlsausführungs-Leistungsfähigkeit

Dieses Kapitel beschreibt die Spezifikaation des DSP KERNES, wie er von den Hardware- und Softwarekonstrukteuren gesehen wird.

2.1 Überblick

Der DSP KERN ist die Basisbaueinheit des MCP und ist allein für die gesamte Berechnung verantwortlich. Sie besteht aus:

- einer 32-Bit ARM7 RISC CPU, die mit 40 MHz läuft und für Allgemeinzweck-Datenverarbeitung, wie Realzeit OS, Un terbrechungs- und Ausnahmehandhabung, Einga be/Ausgabevorrichtungsmanagement, etc. benutzt wird;
- einem Vektorprozessor, der mit 80 MHz läuft und für di gitale Signalverarbeitung, wie Diskrete-Kosinus-Trans formation, FIR-Filterung, Faltung, Video-Bewegungs- Abschätzung etc. benutzt wird. Der Vektorprozessor wird durch die ARM7 initiiert, kann gleichzeitig mit der ARM7 betrieben werden und synchronisiert mit der ARM7 durch spezielle Steuerungsbefehle;
- Ein Cache-Untersystem läuft mit 80 MHz und enthält 1 KB an Befehlen und 1 KB an Daten-Cache für die ARM7, 1 KB Befehle und 4 KB Daten-Cache für den Vektorprozessor und ein gemeinsam genutztes 16 KB an integriertem Befehls- & Daten-Cache ROM für sowohl für die ARM7 als auch den Vektorprozessor. Der Daten-Cache für den Vektorprozessor kann entweder durch die Hardware oder die Software ge steuert werden. Das Cache-Untersystem bildet mit der ARM7 durch die 32-Bit Datenbusse und mit dem Vektorpro zessor durch die 128-Bit Datenbusse Schnittstellen;
- ein 32-Bit, 40 MHz Eingangs- und Ausgangsbus (IOBUS), wel cher mit verschiedenen internen Peripheriegeräten, wie Bitstromprozessor, Befehlssteuerungseinheit, Zeitsteue rung und UART Schnittstellen bildet;
- ein 64-Bit, 80 MHz schneller Eingangs-/Ausgangsbus (FBUS), welcher mit der PCI Bus-Steuerungseinheit, der Speichersteuerungseinheit, der DMA Steuerungseinheit und dem logischen Kunden-ASIC-Block Schnittstellen bildet.

Ein Blockdiagramm des DSP KERNES wird in der Fig. 10 gezeigt.

2.2 ARM7 RISC CPU 2.1 Überblick

Die ARM7 RISC CPU ist ein 32-Bit RISC Prozessorkern für All gemeinzwecke. Er ist mit dem Vektorprozessor über die Stan dard-Coprozessor-Schnittstelle verbunden und wird benutzt, um die meisten nicht berechenbaren intensiven Funktionen in dem MCP, wie Realzeit OS, UO Vorrichtungsunterbrechungshandhabung und Kommunikation mit der Hauptrechner-CPU handzuhaben.

Die ARM7 CPU Merkmale:

- komplett statischer Betrieb, ideal für leistungssensible Anwendungen,
- niedriger Leistungsverbrauch: 0,6 mA/MHz @ 3 V Herstel lung,
- hohe Leistungsfähigkeit: 25 MIPs @ 40 MHz (40 MIPs Peak) @ 3 V,
- Großer und Kleiner Endian Betriebsmodus,
- schnelle Unterbrechungsantwort für Realzeitanwendung (22 Taktzyklen bei 40 MHz),
- einfacher, aber leistungsstarker Befehlssatz,
- sehr kompaktes Layout. Ungefähr 6 mm².

2.2.2 Register

Die ARM7 hat insgesamt 37 Register, welche 31 Allgemeinzweck- Register und 6 Statusregister beinhalten. Zu jeder Zeit gibt es 16 Allgemeinzweck-Register und ein oder zwei Statusregi ster, die für den Programmierer sichtbar sind. In all den Prozessormoden des Benutzers, Überwachers, IRQ, FIQ, Abbre chung und undefiniert, kann auf R0 und R15 direkt zugegriffen werden.

Alle Register mit Ausnahme des R15 sind für den allgemeinen Zweck und können benutzt werden, um die Daten oder die Adres senwerte zu halten. Das Register 15 hält den Programmzähler (PC). Das Statusregister und die CPSR-Register mit dem aktu ellen Programmstatus enthalten die ALU Markierungen (Flag) und die Bits des aktuellen Modus.

R14 wird als das Subroutine-Verbindungsregister benutzt und empfängt eine Kopie des R15, wenn ein Verzweigungs- und Ver bindungsbefehl ausgeführt wird. Es kann als ein Allgemein zweckregister zu allen anderen Zeiten benutzt werden.

Allgemeinzweckregister und Programmzähler

Programmstatusregister

2.2.3 Ausnahmen

Ausnahmen sind unnormale Zustände, die während der Befehls verarbeitung auftreten, welche den Steuerungsfluß dazu veran lassen, sich zu ändern. Es gibt sieben Typen von ARM7 Ausnah men, wie diese unten von der höheren bis zur niedrigeren Priorität aufgelistet werden:

- Zurücksetzen (höchste Priorität)
- Abbrechen (Daten)
- FIQ
- IRQ
- Abbrechen (vorher abrufen)
- undefinierter Befehlstrap, Software-Unterbrechung (nied rigste Priorität)

Ausnahmenvektortabelle

2.2.4 Befehlssatz

Alle ARM7 Befehle werden bedingt ausgeführt, was bedeutet, daß ihre Ausführung abhängig von den Werten der N, Z, C, V Markierungen (Flags) in dem CPSR Register stattfinden können oder nicht können.

ARM7 Befehle können in verschiedene Kategorien aufgeteilt werden:

- Verzweigung und Verzweigung mit Verbindung (B, BL)
- Datenverarbeitung (AND, EOR, SUB, RSB, ADD, ADC, SBC, RSC, TST, TEQ, CMP, CMN, ORR, MOV, BIC, MVN)
- PSR Übertragung (MRS, MSR)
- Multiplikation und Multiplikationsakkumulierung (MUL, MLA)
- Einzeldatenübertragung (LDR, STR)
- Blockdatenübertragung (LDM, STM)
- Einzeldatenauslagerung (SWP)
- Software-Unterbrechung (SWI)
- Coprozessordatenbetrieb (CDP) (dies ist eine Gruppe von Befehlen)
- Coprozessordatenübertragung (LDC, STC)
- Coprozessorregisterübertragung (MRC, MCR)

2.3 Vektorprozessor 2.3. Überblick

Der Vektorprozessor ist ein leistungsstarker digitaler Si gnalprozessor, der die Einzelbefehls-Mehrfachdaten (SIMD)- Architektur für maximale Leistung verwendet. Er besteht aus einem Pipeline-RISC-Prozessor, der parallel auf Mehrfachda tenelemente einwirkt, um höchste Leistung zu erreichen. Die Mehrfachdatenelemente werden in einen 576-Bit Vektor gepackt, welche berechnet werden können bei der Rate von:

- zweiunddreißig 8/9-Bit Festpunkt-Arithmetikfunktionen bei jedem 12,5 ns Zyklus oder
- sechzehn 16-Bit arithmetische Festpunkt-Funktionen bei jedem 12,5 ns Zyklus oder
- acht arithmetische 32-Bit Festpunkt-oder Gleitpunkt- Funktionen bei jedem 12,5 ns Zyklus.

2.3.2 Ausführungs-Pipelines

Der Vektorprozessor verwendet eine sechsstufige Pipeline zur Befehlsausführung, wie in Fig. 11 dargestellt.

Die meisten 32-Bit Skalaroperationen werden mit der Rate von einem Befehl pro Zyklus zeitverschachtelt ausgeführt, wohin gegen die meisten 576-Bit Vektoroperationen bei der Rate von einem Befehl bei jeweils 2 Zyklen zeitverschachtelt ausge führt werden. Jedes Laden und Speichern wird mit arithmetischen Operationen überlappt und wird unabhängig durch separate Lade- und Speicher-Hardware ausgeführt.

Um zwischen der Designkomplexität und der Leistung auszuglei chen, kann der Vektorprozessor Befehlsstörungen ausgeben und ausführen durch Benutzen von Hardware-Sperrungen für sowohl Systemelement-als auch Datenabhängigskeitsüberprüfung. Dieses Merkmal verbessert wesentlich die Durchführung insbesondere während der Daten-Cache-Fehlgriffe aufgrund des Ladens und Speicherns.

2.3.3 Hardware-Mikroarchitektur

Der Vektorprozessor besteht aus 4 hauptsächlichen Funktions- Blöcken, wie in Fig. 12 dargestellt:

- Befehlsabrufeinheit (IFU)
- Befehlsdecodierer und -ausgeber
- Befehlsausführungsdatenweg
- Lade- und Speichereinheit (LSU)

Die Befehlsabrufeinheit ist für das vorherige Abrufen von Be fehlen und das Verarbeiten von Steuerungsflußbefehlen, wie der Verzweigen-und-Springen-zu-Subroutine, verantwortlich. Die IFU enthält eine 16-Eingangs-Warteschlange von vorher ab gerufenen Befehlen für den aktuellen Ausführungsstrom und ei ne 8-Eingangs-Warteschlange von vorher abgerufenen Befehlen für den Verzweigungszielstrom. Die IFU kann 8 Befehle von dem Befehls-Cachespeicher bei jedem Zyklus empfangen.

Der Befehlsdecodierer- und -ausgeber ist zum Decodieren und Steu ern von allen Befehlen verantwortlich. Der Decodierer kann eine Befehl pro Zyklus und immer in der Reihenfolge des An kommens des Befehls (von der IFU) verarbeiten, obwohl der Ausgeber die meisten Befehle, die außer der Reihenfolge sind, steuern kann, abhängig von sowohl dem Ausführungsbetriebsmit tel als auch der Operanden-Daten-Verfügbarkeit.

Der Vektorprozessor erzielt viel seiner Leistung durch ver schiedene 288-Bit Datenwege (Fig. 13), die bei 12,5 ns/Zyklus laufen, die enthalten:

- Vier-Anschluß-Registerdatei, welche 2 Lesevorgänge und 2 Schreibvorgänge pro Zyklus unterstützen kann;
- acht 32×32 Parallel-Multiplizierer, die alle 12,5 ns entweder acht 32-Bit Multiplikationen (in Ganzzahl- oder Gleitpunktformat) oder sechzehn 16-Bit Multiplikationen oder zweiunddreißig 8-Bit Multiplikationen vornehmen können;
- acht 36-Bit ALUs (Rechen-und Steuerwerk), die alle 12,5 ns entweder acht 36-Bit ALU Funktionen (in Ganzzahl- oder Gleitpunktformat) oder sechzehn 16-Bit ALU Funktio nen oder zweiunddreißig 8-Bit Funktionen ausführen kön nen.

Die Lade- und Speichereinheit ist aufgebaut, um Schnittstellen mit dem Daten-Cachespeicher durch separate Lese- und Schreibe- Datenbusse zu bilden, wovon jeder 288 Bit breit ist, wie in Fig. 14 dargestellt.

2.3.4 Unterbrechung und Ausnahme

Der Vektorprozessor erkennt nur 2 spezielle Zustände:

- CPINT (Coprozessorunterbrechung) Befehl, wie durch die ARM7 Programme ausgeführt,
- Hardware-Stapelüberlauf als ein Ergebnis von Mehrfach- und geschachtelten Sprung-Subroutine-Befehlen, die durch die Vektorprozessorprogramme ausgeführt werden.

Bitte beziehen sie sich auf das Vektorprozessor- Architekturdokument für nähere Details im Hinblick darauf, wie der Vektorprozessor diese 2 eindeutigen Zustände hand habt.

Alle anderen Unterbrechungs-und Ausnahmezustände, die in den MCP erzeugt werden, werden nur durch die ARM7 gehandhabt.

2.4 Cache-Untersystem 2.4.1 Überblick

Die Cache-Steuerungseinheit (CCU) bildet Schnittstellen mit dem ARM7 Kern, der Vektorausführungseinheit (LSU, IFU), dem Speicher (MCU, PCI, DMA, CODEC) und den 10-Vorrichtungen (BP, UART, Zeitsteuerung, Unterbrechungssteuerungseinheit). Sie bildet Schnittstellen sowohl mit dem Hochgeschwindigkeits- (80 MHz)-FBUS und einem Niedriggeschwindigkeits- (20 MHz)-IOBUS. Sie wird eigentlich zur zentrale Datenübertragungseinheit zwischen allen internen CPU-Kerneinheiten und den peripheren IO-Vorrichtungen. Für ein besseres Bild der CCU in dem MSP- Chip beziehen sie sich bitte auf das Blockdiagramm (S. 1-10) in der MSP-1E Systembeschreibung.

Um ein sehr hochleistungsfähiges Cachesystem zu unterstützen, hat die CCU ein auf Transaktionen beruhendes Protokoll be nutzt, um alle Lese- und Schreiboperationen zu unterstützen. Jede Einheit, wenn sie auf den Speicher zugreifen muß, kann die Anfrage an die CCU-Steuerungseinheit stellen. Die Ent scheidungseinheit in der Steuerungseinheit kann die Anfrage basierend auf einer festgelegten Priorität erteilen und eine transaction_id an den Anfrager zurückgeben. Der Anfrager sollte diese transaction_id behalten, um so die zurückgekom menen Daten zu erkennen, wenn die Daten tatsächlich ankommen. Während die CCU-Steuerung die Anfrage von einer Einheit ver arbeitet (welches viele Zyklen in Anspruch nehmen kann, wenn ein Cache-Fehlgriff stattfindet), kann eine neue Anfrage von einer anderen Einheit in dem nächsten Zyklus mit einer unter schiedlichen transactions_id erteilt werden. Auf diese Art wird die anhängige Anfrage niemals irgendeine nachfolgende Anfrage von einer anderen Einheit blockieren, und hohe Lei stungsfähigkeit wird erreicht. Momentan kann die CCU eine Le seanfrage und eine Schreibeanfrage gleichzeitig in einem Zy klus akzeptieren und erteilen.

Die Schnittstelleneinheit zu dem Speicher (FBUS) ist aus ei ner Vier-Eingangs-Adressenwarteschlange und einer Ein- Eingangs-Rückschreibeverriegelung zusammengesetzt.

Sie kann in ihrem besten Zustand eine anhängige Auffüll (Le se)-Anfrage von dem ARM Befehls-Cache, eine anhängige Auffüll (Lese)-Anfrage von dem VEC-Befehlscache, eine Schreibeanfrage von dem VEC-Datencache und eine Rückschreibeanfrage von dem VEC-Datencache aufgrund schmutziger Cacheleitung unterstüt zen.

Der Cachespeicher selber ist ebenso für hohe Leistungsfähig keit optimiert. Das MSP Cache-System enthält sowohl einen auf dem Chip befindlichen Cache SRAM und Cache ROM. Der Cache SRAM wird weiterhin in vier verschiedene Banken aufgeteilt, um Datenausschuß zwischen der ARM CPU und dem Vektorkern oder zwischen der Befehl und den Daten zu vermeiden. Der Cache ROM sieht ein Hochgeschwindigkeits- und Hochdichtedatenspeiche rungsgebiet für die ARM7 und den Vektorkern vor. Obwohl die Markierung für den Cache ROM nicht verändert werden kann, kann das gültige Bit abgeschaltet werden, so daß Daten zurück zu dem externen Speicher gebracht werden können. Zusammenge faßt enthält der auf dem Chip befindliche Cachespeicher die folgenden Blöcke:

- einen 1 kB direkt-zugeordneten Befehlscache und einen 1 kB direkt zugeordneten Rückschreibedatencache mit einer 32-Bit Datenbusschnittstelle zu der ARM7;
- einen 1 kB direkt-zugeordneten Befehlscache mit 256-Bit Busschnittstelle zu der Vektorbefehlsaufrufeinheit;
- einen 4 kB direkt-zugeordneten Rückschreibedatencache mit 256-Bit Busschnittstelle zu der Vektorausführungs einheit. Der Datencache weist eine Doppelzugriffsmög lichkeit auf: Er kann 256 Bits an Lesedaten liefern und er kann 256 Bits an Schreibedaten bei jedem Zyklus bei 80 MHz unterstützen;
- der 4 KB VEC Datencache kann als Notizblockspeicher bzw. Zwischenspeicher konfiguriert werden, der unter Softwaresteuerung arbeitet;
- einen gemeinsam genutzten integrierten Befehls- und Daten- ROM-Cache für die Benutzung durch sowohl den ARM7 als auch den Vektorprozessor. Die Schnittstelle zu dem ARM7 erfolgt durch denselbigen 32-Bit Bus, wie sein Befehls sungscache, und die Schnittstelle zu dem Vektorprozessor erfolgt durch denselbigen 256-Bit Bus wie sein Befehl scache;
- Mit fünf Anschlüssen:
- - Lese/Schreibeanschluß für ARM7,
- - Leseanschluß für die Befehlsaufrufeinheit des Vek torprozessors,
- - Lese/Schreibeanschluß für die Lade/Speichereinheit des Vektorprozessors,
- - Lese/Schreibeanschluß für den IJO Bus des Vektor prozessors,
- - Lese/Schreibenanschluß für den FBUS;
- 32×256-Bit SRAM (∼1 kB) für ARM7 CPU Befehlscache;
- 32×256-Bit SRAM (∼1 kB) für ARM7 CPU Datencache;
- 128×256-Bit SRAM (∼4 kB) für Vektorprozessor-Daten cache;
- 32×256-Bit SRAM (∼1 kB) für Vektorprozessor- Befehlscache;
- 512×256-Bit ROM (∼16 kB) für Daten- und Befehlscache.

Die Steuerung des Vektordatencaches kann entweder unter Hard waresteuerung oder durch Softwaresteuerung durchgeführt wer den.

2.4.2 Cache-Untersystem-Organisation

Fig. 15 ist ein Blockdiagramm des MSP Cache-Systemes. Es be steht aus den folgenden Blöcken: IDC (Befehlsdatencache), Cache ROM, CCU_DATEN_DP, CCU_ADR_DP, CCU_CTL und CCU_SM. Je der Unterblock wird im näheren Detail beschrieben werden.

2.4.2.2 IDC

Der Befehls-und Datencache (IDC; siehe Fig. 16) ist der auf dem Chip befindliche SRAM Speicher, welcher für das Abarbei ten der Befehls- und der Datencachezugriffe benutzt wird. Er besteht aus vier Speicherbänken in einer Reihe: ARM_IC (1 KB), ARM_DC (1 KB), VEC_IC (1 KB) und VEC_DC (4 KB). In jedem Zyklus kann er eine Leseanfrage und eine Schreibeanfrage ak zeptieren. Der Markierungs-RAM hat zwei Leseanschlüsse. Die Leseanschlußadresse und die Schreibanschlußadresse können mit den internen Cache-Markierungen für einen Treffer-oder Fehl griffszustand verglichen werden. Der Daten RAM hat nur einen Leseanschluß, auf den durch die Leseanschlußadresse zugegrif fen wird. Sowohl der Markierungs-RAM als auch der Daten-RAM können durch Benutzen eines unterschiedlichen Satzes von Schreibadressen ebenso beschrieben werden. Deshalb werden vier Sätze an Cache-Bankauswahlsignalen und drei Sätze an Leitungsindizes benötigt, um auf die Cache-Reihe zuzugreifen.

Der IDC hat die folgenden Eigenschaften:

- direkt zugeordnet mit Rückschreibeverhalten;
- die Cacheleitungsgröße ist 64 B, jedoch die Datenbreite ist nur 32 B, welches ebenso die Vektordatengröße des MSP-Chips ist;
- jede Leitung hat zwei gültige Bits, eines für den hohen Vektor und eines für den niedrigen Vektor. Zusätzlich hat der Datencache zwei schmutzige Bits (Speichermarke), eines für jeden Vektor.
- Die Markierungsgröße ist 22 Bit (Adressenbit 10 - Bit 31) für ARM_IC, ARM_DC und VEC_IC. Sie hat 20 Bit (Adressenbit 12 - Bit 31) für VEC_DC.
- Die Leitungsindexbits sind 5 Bit (Adressenbit 5 - Bit 9) für ARM_IC, ARM_DC und VEC_IC. Es sind 7 Bits (Adressen bit 5 - Bit 11) für VEC_DC.
- VEC_DC (4 KB) kann als Zwischenspeicher mit der Soft waresteuerung rekonfiguriert werden.
- V_CLEAR Signal wird benutzt, um global die Cachelei tungs-Gültigkeits-Bits alle auf einmal zurückzusetzen.

In Zukunft wird der V_CLEAR selektiv nur die individuel le Bank zurücksetzen.

2.4.2.3 Datenweg-Pipeline

Siehe Fig. 17.

2.4.2.4 Adressenweg-Pipeline

Die Datenwege für die Adressenverarbeitungspipeline werden in Fig. 18 gezeigt.

CCU ADRESSEN DP 2.4.3 Schnittstelle 2.4.3.1 Datentyp

CCU behandelt die verschiedenen Datentypen von verschiedenen Anfrageeinheiten, wie in Tabelle 15 dargestellt.

CCU-Betrieb beim Behandeln von verschiedenen Datentypen

2.4.3.2 ARM Schnittstelle

Der ARM7 CPU Kern läuft mit der Hälfte der Frequenz (40 MHz), wohingegen die CCU bei der vollen Frequenz (80 MHz) des msp Chips läuft. Die Synchronisation zwischen diesen zwei Takten ist in dem Aufbau wichtig. Als eine allgemeine Regel wird die Taktgeneratoreinheit den MCLK nur bei der ansteigenden Kante des CLKI schalten. Ebenso wird das globale Zurücksetzungs signal, welches mit der ARM7 verbunden ist, nur deaktiviert, wenn sowohl die CLK1 als auch die MCLK niedrig sind. Auf die se Weise werden beide Einheiten sauber synchronisiert sein.

Obwohl die ARM7 nur einen Eingangsbus (ARM_DATA <31 : 0<) für Befehl und Daten hat, ist der rasp-Chip mit einem reservier ten Befehlsspeicher (ARM _IC, IKB) und einem Datencache (ARM _DC, 1 KB) ausgestattet. Die CCU kann zwischen diesen zwei Arten von Anfrage, die die ARM_NOPC benutzen, unterscheiden.

Um die Leistung weiterhin zu verbessern, hat die CCU einen Mikrobefehlscache (UI_CACHE, 32 B) und einen Mikrodatencache (UD_CACHE, 32 B) hinzugefügt, um zwischen dem Hauptcache und dem ARM7-Kern zu sitzen. Diese Caches enthalten 8 Wörter in jedem Wert von sequentiellem Code und Daten. Diese Mikro caches enthalten ihre eigene Markierung (27-Bit), Markie rungskomparatoren und gültige Bits. Während des Systemrück setzens werden diese gültigen Bits alle gelöscht.

Die ARM7-Mikrocaches arbeiten mehr wie ein Vorher-Abrufpuffer als ein echter Cache. Während die ARM7 liest, wird die Adres se (ARM_A<31 : 0<) immer mit der Markierung verglichen. Ein Treffer wird den Befehl oder die Daten durch die ARM_DATA <31 : 0< zurücklesen. Eine Mikrocache-Fehlgriff wird dann die Anfrage an die CCU senden, zusammen mit der Adresse, dem Da tentyp und anderen Steuerungsinformationen. Die CCU Entschei dungseinheitlogik wird die Anfrage von allen Einheiten durch Herstellen einer Leseanfrage erteilen. Momentan hat die ARM7 die höchste Priorität über andere Blöcke beim Bekommen der Erteilung. Dies ist aufgrund der Tatsache, daß die ARM7 rela tiv selten eine Anfrage erstellt, wenn nicht ihr Mikrocache einen Fehlgriff gemacht hat. Jedoch könnte die CCU interne Haltezyklen haben, um die Mehrfachzyklusanfrage- oder Adres senwarteschlangevollzustände abzuarbeiten. Während dieser Pe riode wird keine Anfrage von außerhalb gewährt werden.

Das Schreiben von der ARM7 wird immer den UD_CACHE ungültig machen, wenn die Adresse die UD_TAG trifft. Kein Versuch wird gemacht, um den U-D_CACHE als entweder einen Durchschreibe- oder Rückschreibecache aufzubauen. Durch das Erzwingen der Ungültigmachung in dem UD_CACHE Schreibetreffer wird die Da tenkonsistenz zwischen dem ARM_DC und UD_CACHE aufrechterhal ten.

Die CCU steuert die arm_nwait, während sie eine Lese-oder Schreibeanfrage an den ARM_IC oder ARM_DC durchführt. Im all gemeinen hält die CCU nicht das arm_nwait während des Schrei bens. Sobald die Schreibeanfrage erteilt wird, ohne das ccu_write_hold2 zu sehen, treibt die ARM7 einfach die Daten in die ARM-DATA<31 : 0< in dem folgenden Zyklus hinein. Die CCU hat einen internen Schreibepuffer, um die Daten zu halten.

Die ARM7 kann die Befehlsausführung weiter betreiben. Jedoch hält die CCU immer das arm_nwait für einen Zyklus, sogar wenn die Daten in dem Hauptcache vorliegen. Wenn die Lesean frage den Hauptcache verfehlt, werden mehrere Zyklen gehalten werden, bis die Daten von dem außerhalb liegenden Hauptspei cher zurückkehren. Die ARM_CCU Schnittstellenzustandsmaschi ne, die in Fig. 19 gezeigt wird, stellt die Bedingung dar, wie die CCU das arm_nwait steuert.

In Fig. 19:

START: Der Startzustand für die Zustandsmaschine, wenn entwe der keine Anfrage, oder Lesedaten zurückgegeben werden, oder Schreibanfrage ohne Halten.

HOLD (HALTEN): Die CCU erteilt der ARM7 Anfrage zum Lesen und Schreiben, jedoch widerruft die Erteilung mit dem Haltesi gnal.

MARKIERUNG (TAG): Die CCU überprüft die Markierung mit der Lese-Adresse.

FEHLGRIFF (MISS): Die Leseadresse hat einen Fehlgriff und die CCU sendet eine Rückfüllanfrage an den außerhalb liegenden dram aus.

DATEN (DATA): Die Lesedaten werden zurückgegeben und die CCU bringt sie zu dem Mikrodatencache.

2.4.3.3 FBUS Schnittstelle

Die CCU_FBUS Schnittstellenzustandsmaschine (F_SM) wird in der Fig. 20 gezeigt. In Fig. 20:

LEERLAUF (IDLE): Leerlaufzustand.

ANFRAGE (REQ): stellt Lese- oder Schreibeanfragen an die FBUS-Entscheidungseinheit.

GRT1: Erteilungsgröße ist größer als 8 B.

GRT2: Erteilungsgröße ist größer als 16 B.

GRT3: Erteilungsgröße ist größer als 24 B.

GRT4: Ansteuerdaten für den letzten Zyklus.

Die Datenempfängerzustandsmaschine (D_SM) wird in Fig. 21 ge zeigt. In Fig. 21:

LEERLAUF (IDLE): Leerlaufzustand.

EINS (ONE): empfängt die ersten 8B Daten von Fdata <63 : 0<.

ZWEI (TWO): empfängt die zweiten 8B Daten von Fdata <63 : 0<.

DREI (THREE): empfängt die dritten 8B Daten von Fdata <63 : 0<.

VIER (FOUR): empfängt die vierten 8B Daten von Fdata <63 : 0<.

WIEDERAUFFÜLLEN (REFILL): füllt die IDC wieder auf, bevor die Daten an den Anfrager zurückgegeben werden.

RDY: liest und gibt Daten an den Anfrager zurück.

2.4.4 Lese- und Schreiboperationen

Die Lese- und Schreib-Zustandsmaschinen werden in Fig. 22 ge zeigt.

2.4.4.1 Leseoperation

Der IDC (Befehls-und Datencache) im MSP wird in drei Zustän den der Pipelinezyklen betrieben: Anfragezyklus, Markierungs zyklus und Datenzyklus. In dem Cachetrefferfall ist der IDC dazu imstande, die Befehle oder Daten in jedem Zyklus zurück zugeben.

Die Cache-Steuerungseinheit (CCU) führt Arbitration in der ARM7, der Vektorprozessoreinheit, dem Fbus und dem IObus für SRAM Cache Zugriff durch. Die CCU überwacht die Busanfragen von diesen vier Mastern und macht den Bus zu dem Gewinner mit einer spezifischen ID Nummer. Die CCU erzeugt ebenso den Cache-Adressenbus- und die Lese/Schreibesteuerungssignale, um auf den Cache zuzugreifen und den Markierungsvergleich durch zuführen.

Wenn es einen Cache-Treffer gibt, wird der Busmaster, welcher die Arbitration (Entscheidung) gewonnen hat, dazu imstande sein, auf den Cache für die Lese/Schreibefunktion zuzugrei fen. Wenn es einen Cache-Fehlgriff gibt, dann wird die CCU den nächsten Busmaster bedienen, welcher eine Anfrage gemacht hat, ohne auf die fehlenden Daten zu warten, die von dem Hauptspeicher zurückkommen. So muß der Busmaster, welcher ei ne Cachefehlgriff hat, die ID-Nummer beibehalten. Später, wenn die angefragten Daten in dem Cache sind, wird die CCU das GRANT-Signal an den Busmaster mit den fehlende Daten mit der gleichen ID-Nummer senden. Dieser Busmaster kann Daten akzeptieren oder die Daten ignorieren.

Wenn es einen Cachefehlgriff gibt, wird ein Leitungsabruf durchgeführt werden, um die Daten von dem Hauptspeicher zu bekommen. Die Leitungsgröße ist als 64 Byte definiert, so daß die CCU 8 aufeinanderfolgende Speicherzugriffe (64 Bit je weils) ausführen wird, um die Daten von dem Hauptspeicher zu dem Cache zu bekommen.
-Anfragezyklus:
Die CCU wird die Leseanfrage von den verschiedenen Einheiten (ARM, IFU, LSU, IO) in dem CLK1 annehmen. Der Anfrager wird das Anfragesignal (lsu_req) und das Lese/Schreibesignal (lsu_rw) im frühen CLK1 aktivieren. Mit dem Ende des CLK1 wird die CCU eine dieser Leseanfragen durch Ausgeben von ccu_grant_id [9 : 0] erteilen. Wenn ccu_grant_id [9 : 6] mit unit_id des Anfragers übereinstimmt, dann wird die Anfrage erteilt. Der Anfrager sollte ccu_grant_id [5 : 0] zwischenspei chern, da es die Transaktions id(Identifikation) ist, die mit der Anfrage verbunden wird.

Wenn die Anfrage erteilt wird, sollte der Anfrager die Adres se (lsu_adr [3 1 : 0]) und andere Steuerungsinformationen, wie cache_off Betrieb (lus_ccu_aus) und Datentyp (lsu_vec_typ [1 : 0], lsu_data_typ [2 : 0]) im CLK2 an die CCU lossenden.

Wenn ccu_rd_hold_2 nicht durch das Ende des CLK2 aktiviert wird, dann wird die Anfrage durch die CCU komplett übernommen und die angefragten Daten werden etwas später zurückgesendet werden. Jedoch, wenn ccu_rd_hold_2 aktiviert wird, sollte der Anfrager das Los senden der Adresse und der Steuerungssignale beibehalten, als wenn die erteilte Anfrage in dem CLK1 zu rückgenommen wird. In dem nächsten Zyklus gibt es keinen Be darf, dieselbe Leseanfrage wiederum durchzuführen, da alle vorangegangenen grant_id Informationen immer noch gültig sind. Das ccu_rd_hold_2 wird in dem CLK1 konstant bleiben, bis es durch die CCU in dem CLK2 deaktiviert wird.

Das ccu_rd_hold_2 ist ein zeitsteuerungskritisches Signal. Es wird benutzt, um den Anfrager zu informieren, daß die CCU da mit beschäftigt ist, andere Dinge in dem vorliegenden Zyklus zu handhaben, und die erteilte Anfrage jetzt nicht verarbei tet werden kann.
-Markierungszyklus:
Wenn die Anfrage erteilt wird und nicht später in dem Anfra gezyklus widerrufen wird, wird sie in die Markierungsverglei chungsstufe des Cachezugriffes eintreten. Die CCU wird die Adresse (lsu:adr [11 : 5]) und das Bankauswahlsignal (Anfrager) benutzen, um die Leitungsauswahl für das Markierungslesen durchzuführen. Das Markierungstreffersignal (ccu_!su_hit_2) wird auf das Ende des CLK2 zu bekannt sein. Die Daten werden in dem nächsten Zyklus für den Trefferfall zurückgesendet werden. Die Leseanschlußmarkierung wird herausgehen und durch die CLK2 irgendwie verriegelt bzw. zwischengespeichert wer den.

Der Adressenwarteschlangenstatus wird ebenso in diesem Zyklus ausgewertet werden. Der Markierungsfehlgriff und eine al most_full_address_queue (fast_volle_adressen_warteschlange) wird das ccu_rd_hold_2-Signal aktivieren. Die CCU- Zustandsmaschine wird keine neuen Leseanfragen handhaben, je doch wird sie den abgebrochenen Markierungsvergleich wieder holen.

Da jede Cacheleitung (64B) zwei Vektoren enthält, sollte das gültige Bit des zugreifenden Vektors gültig sein, um einen Markierungstreffer zu bekommen. Für Doppelvektor (64B)- Datenlesen müssen beide gültigen Bits gültig sein, um den Markierungstreffer zu bekommen. Der cc_off-Betrieb wird immer einen Markierungsfehlgriff erzwingen und die Anfrage wird in die Adressenwarteschlange eingegeben werden.
- Datenzyklus:
Dies ist der Zyklus, in der die CCU die Daten zu dem Anfrager zurückgibt. Die Daten werden auf ccu_dout [127 : 0] gegeben, wobei die niedrigen 16B bei CLK1 angesteuert werden und die hohen 16B bei CLK2 angesteuert werden. Für die 64B Datenan frage wird ein zusätzlicher Zyklus benutzt, um die Übertra gung zu beenden.

Die CCU wird immer ccu_data_id [9 : 0] einen halben Zyklus frü her (CLK2) ansteuern, um den Anfrager zu informieren, daß die Daten in dem folgenden CLK1 zurückgegeben werden. Der Anfra ger sollte immer ccu_data_id [9 : 0] für die sauberen zurückge gebenen Daten vergleichen. Zusätzlich wird der Markie rungstreffer ebenso als eine Anzeige für die zurückgegebenen Daten benutzt.

Wenn es einen Markierungsfehlgriff in dem Markierungszyklus gibt und die Adressenwarteschlange nicht voll ist, wird die CCU den Cache-Leitungsabruf durch Eingeben der fehlenden Adresse, der id-Information und anderer Steuerungsinformation in die Vier-Eingangs-Adressenwarteschlange in dem CLK1 star ten. Augenblicklich enthält jede Adressenwarteschlange unge fähr 69 Bit an Information. In dem CLK2 wird die Speicher adressenverriegelung so geladen sein, daß die FBUS-Anfrage in dem nächsten CLK1 durchgeführt werden kann.

2.4.4.2 Schreiboperation

99999 00070 552 001000280000000200012000285919988800040 0002019735880 00004 99880

Die Schreiboperation in dem IDC wird ebenso in 3 Stufen der Pipelinezyklen betrieben: Anfrage- bzw. Anforderungszyklus, Markierungszyklus, Datenschreibzyklus. In dem Schreibadres sentrefferfall ist die IDC dazu imstande, Daten an die Cache- Datenreihe in jedem Zyklus zu schreiben.
-Anfragezyklus:
Die CCU wird die Schreibeanfrage von verschiedenen Einheiten (ARM, LSU, IO) in dem CLK1 akzeptieren. Der Anfrager wird das Anfragesignal (lsu:req), das Lese/Schreibesignal (lsu_rw) und den Vektortyp (lsu_vex_typ [1 : 1]) in dem frühen CLK1 aktivie ren. Mit dem Ende des CLK1 wird die CCU eine dieser Schreibanfragen bewilligen. Die Schreibbewilligung für die verschiedenen Einheiten wird durch Aktivieren eines Bewilli gungssignales (ccu lsu wr_grant) an die Anfrageeinheit direkt durchgeführt. Es gibt keinen Bedarf für die Anfrageeinheit, eine Transaktions-id von der CCU zu empfangen, da keine Daten zurückgegeben werden. In dem CLK2 sollte der Anfrager die Adresse (lsu_adr [31 : 0]), das cc_off-Signal (lsu_ccu_off) und den Datentyp (lsu_data_type [2 : 0]) liefern.

Genau wie in dem Lesefall könnte die CCU ccu wr hold_2 in der Nähe des Endes von CLK2 aktivieren, um den Anfrager zu informieren, daß, obwohl die Bewilligung gegeben worden ist, sie jedoch nicht in dem vorliegenden Zyklus verarbeitet wer den kann. Der Anfrager sollte die Ansteueradresse, das cc_off-Signal und die Datentypinformation beibehalten, bis ccu wr hold_2 deaktiviert wird. Dann wird in dem folgenden Zyklus der Anfrager die Schreibedaten an ccu_dout [127 : 0] liefern.
-Markierungszyklus:
Wenn die Anfrage bewilligt wird und später nicht in dem An fragezyklus widerrufen wird, wird sie in den Markierungsver gleichszustand des Cache-Zugriffes eintreten. Dies ist der Schreibanschlußadressenmarkierungsvergleich. Die CCU wird die Adresse (lsu_adr [11 : 5]) und das Bankauswahlsignal (Anfrager) benutzen, um die Leitungsauswahl für den Cache durchzuführen. Das Markierungstreffersignal (ccu lsu hit_2) wird bis an das Ende des CLK2 bekannt sein. Das cc_off Schreiben wird immer einen Markierungsfehlgriff erzwingen, und die Schreibdaten werden auf den FBUS für externes Schreiben gegeben.

Der Anfrager sollte das Ansteuern der Daten zu ccu_din [143 : 0] mit den niedrigen 16B in dem CLK1 und den oberen 16B in dem CLK2 starten. Für die 64B-Datenübertragung wird der Anfrager einen zusätzlichen Zyklus zum Steuern der Daten neh men. Es sollte angemerkt werden, daß die CCU eine interne Schreibedatenverriegelung hat, um diese Daten zu halten. Wenn dieser Schreibvorgang den Cache trifft (nimmt einen oder zwei Zyklen für die tatsächlichen Schreibdaten in den Cache) oder den Cache verfehlt (kann einige wenige Zyklen nehmen, um die Daten zu schreiben), sollte der Anfrager nun berücksichtigen, daß der Schreibvorgang beendet wird.
- Datenschreibzyklus:
Dies ist der Zyklus, bei dem die CCU tatsächlich Daten in den Cache für den Cache-Trefferfall schreibt. Wenn es einen Mar kierungsfehlgriff in dem Markierungszyklus gibt, so wird die CCU ihn unterschiedlich, abhängig von dem Datentyp, behan deln.

Wenn der Datentyp 32B ist und die Leitung sauber ist (beide Vektoren sind leer), so wird die CCU einfach die existierende Leitung mit der neuen Markierung und den neuen Daten über schreiben. Sie wird ebenso den zugreifenden Vektor als gültig und schmutzig markieren, während der andere Vektor in dersel ben Leitung als ungültig zurückgelassen werden.

Wenn der Datentyp weniger als 32B ist, wird dies das teilwei se Datenschreiben. Diese Teildaten werden auf einem temporä ren Register gehalten. Die CCU wird herangehen, die fehlende Halbleitung (32B) vom Speicher abzurufen, und lädt sie zurück in den Cache. Die Teildaten werden dann mit den geeigneten Byte-Freigabesignalen in die Cacheleitung geschrieben.

Für alle Schreibfehlgriffe mit einer schmutzigen Cacheleitung wird die CCU zuerst die schmutzige Leitung herauskopieren. Da die schmutzigen Daten nicht jetzt erhältlich sind, wird die CCU das Halten für die Bewilligungs-Logik aktivieren, so daß keine neue Lese- oder Schreibeanfrage erteilt wird. Sie wird dann ein internes Lesen durch Benutzen der Adresse der schmutzigen Leitung starten, um die schmutzigen Cache- Leitungsdaten abzurufen. Schließlich werden die Rückschrei beadresse und die Daten zu dem Speicher herausgehen.

2.4.5 Programmiermodell

Das Cache-Untersystem wird insgesamt in der Hardware durch das Benutzen von Lade- und Speicher-Befehlen gesteuert und des halb erfordert es nicht irgendwelche software-sichtbaren Re gister.

2.4.6 IDC und ROM Adressenformat wird in der Fig. 23 ge zeigt.

Kapitel 3 IO BUS Beschreibung

Dieses Kapitel beschreibt die Spezifikation des IOBUS, wie er durch die Hardware-Konstrukteure gesehen wird.

3.1 Überblick

Der IOBus ist für "Standard-Peripherie"-Geräte mit langsamer Geschwindigkeit geschaffen, die vom System benutzt werden sollen. Dieser Bus wird als die Hauptschnittstelle zwischen der MSP Cache-Steuerungseinheit (CCU), dem Bitstromprozessor (BSP) und all den anderen IO(Eingabe/Ausgabe)-Peripherie geräten, wie der Zeitsteuerung/-Unterbrechungssteuerungseinheit und dem UART dienen. Das For mat des Busses ist sehr ähnlich dem IO-Bus von Intel. Es gibt eine Bus-Entscheidungs-Steuerungslogik, die konstant den Bus für Anfragen überwacht und die passende Anfrage-Bewilligung erzeugt durch Benutzen eines Round-Robin-Schemas (zyklisches Multiplexverfahren). Der mögliche Busmaster sollte immer die Busanfrage aktivieren und auf die Busbewilligung warten, die aktiviert werden soll, bevor der Bus übernommen wird. Der Busmaster sollte immer die Adresse und die Steuerungsleitun gen für die Dauer des Zyklusses entsprechend dem Protokoll ansteuern.

Der IObus ist ein INSGESAMT synchroner Bus, der bei 40 MHz läuft. Alle Erteilungen bzw. Bewilligungen auf dem MSP IOBUS treten auf, sobald der Zyklus nach der Anfrage als aktiv ab getastet wird. Dieser Bus kann bis zu 16 Byte Übertragungen an Daten über vier Zyklen (Datenkette von vier) handhaben. Dies wird durch Benutzen von zwei Größenbits erreicht, welche der Busentscheidungseinheit die Übertragungsgröße, die von dem Busmaster angefordert wird, anzeigt.

Der IOBus hat einen 32 Bit-Adressen- und Datenmultiplexer. Die Adresse tritt immer als erstes vor den Daten auf. Das IOB_ALE (Adressenverriegelungsfreigabe)-Signal wird durch die empfangenden Vorrichtungen benutzt, um die Adresse zu verrie geln. Jeder Buszugriff wird eine 32 Bit-Übertragung annehmen, sogar wenn eine 8 Bit-Vorrichtung mit dem Bus verbunden ist. Durch normale Konvention wird die 8 Bit-Vorrichtung die nied rigsten 8 Bit [7 : 0] des Busses benutzen und die 16 Bit- Vorrichtung wird die niedrigsten 16 Bit [15 : 0] des Busses be nutzen. Wenn die 16 Bit-Vorrichtung mit der 8 Bit-Vorrichtung kommunizieren will, sollte sie die korrekten Daten auf den untersten 8 Bits des Busses für die 8 Bit-Vorrichtung plazie ren, um die Daten zu sehen und zu verriegeln usw. . Wenn es mehrfache Anfragen in derselben Periode gibt, dann sollten die Anfrager, die keine Bewilligung erhalten haben, immer ih re Anfrage beibehalten, bis sie von der IOBus- Entscheidungseinheit bewilligt werden. Es gibt viele "Bus- Zugriffszyklen" pro Anfrage, die in diesem Schema erlaubt sind, bis zu 4.32 Bit Übertragungsmaximum (16 Bytes). Die Blockübertragung sollte immer in jeweils mehrfache 32 Bit- Übertragungen aufgelöst werden.

Alle Buserteilungen bzw. -bewilligungen werden durch die IOB- Bus-Entscheidungseinheit erzeugt. Jedoch gibt es eine paral lele Decodierlogik, die konstant die Adresse überwacht (wenn gültig) und die passende Chipauswahl (bei dem nächsten Takt zyklus) zu dem Ziel erzeugt. Die Chipauswahl wird IMMER für nur einen Zyklus gültig sein und nachdem die Adresse für ALLE Lese-und Schreibeanfragen aktiviert ist. Jeder IO-Busknoten wird eine bestimmte Chipauswahl als einen Eingang haben. Bit te beziehen sie sich auf die Pin-Beschreibung und die Zeitsteuerungsdiagramme.

Die 2 Bit-Größeninformation sollte durch den Master erzeugt werden, nachdem sie von der Bus-Entscheidungseinheit ERTEILT wird, und sollte für 2 Bus-Zyklen danach GÜLTIG sein. Die ausgewählte Slave-Einheit muß die Größeninformation auffan gen, wenn CS aktiviert ist, um die Busübertragungszyklen zu bestimmen. Wenn geschrieben oder gelesen wird, verfolgt die IOBus-Entscheidungseinheit ebenso die Übertragungsgröße, um zu bestimmen, wann der Buszyklus durchgeführt wird, bevor diese beginnt, nach neuer Anfrage(n) zu suchen. Bitte bemer ken sie, daß es keine "LÜCKE" zwischen den Daten einer Daten kettenbus-Übertragung gibt (ob lesen oder schreiben).

Für Datenleseübertragungen wird ein BEREIT-Signal benutzt, um dem Anfrager anzuzeigen, wenn die Daten gültig sind, und um mit deren Verriegelung zu beginnen. Dieses Bereit wird durch sowohl den Busmaster als auch die Slaveeinheiten erzeugt.

Um dieses Protokoll zu befolgen, müssen alle IO-Busknoten ei ne IO-Busschnittstelle aufbauen, bevor die Anfrage verarbei tet wird. Diese Schnittstelle sollte diesen Spezifikationen entsprechen.

3.2 Pinbeschreibung

Das folgende sind Adressen-, Daten- und Steuerungssignaldefi nitionen für den System-IOBus, wie sie durch den Busmaster gesehen werden. Siehe ebenso Fig. 24, die die IOBUS- Strukturdefinition zeigt. Wie vorher erwähnt, ist der IOBus ein multiplexierter Adressen/Datenbus.

"xxx" ist ein Drei-Buchstaben-Code, der die Anfragernamen identifiziert (ccu, bsp, urt, tmr, int).

System IOBus Signaldefinition

3.3 Logik-Beschreibung

Die IOBus-Entscheidungs-Steuerungseinheit wird in Fig. 25 ge zeigt.

3.4 IOBus Zeitsteuerungen

Die IOBus Lesezeitsteuerung (Übertragungsgröße = 1 Wort (4 Bytes)) wird in Fig. 27 gezeigt.

Die IOBus Schreibezeitsteuerung (Übertragungsgröße = 1 Wort (4 Bytes)) wird in Fig. 2 gezeigt.

Die IOBus Lesezeitsteuerung (Übertragungsgröße = 4 Wörter (16 Bytes)) wird in Fig. 28 gezeigt.

Die IOBus Schreibezeitsteuerung (Übertragungsgröße = 4 Wörter (16 Bytes)) wird in Fig. 29 gezeigt.

Kapitel 4 EBUS-Beschreibung

Dieses Kapitel beschreibt die Spezifikation des FBUS, wie sie durch die Hardware-Konstrukteure gesehen wird.

4.1 Überblick

Die Speicherungssteuerungseinheit, der PCI, das Kunden ASIC und das Cache-Untersystem werden mit dem Systembus "Fbus" über eine nicht multiplexierte Adressen- und Datenbusleitun gen Schnittstellen bilden. Es wird eine zentrale Fbus Ent scheidungssteuerungslogik geben, die die Anfragen überwachen wird und die Erteilungen durch Benutzen von einigen Priori tätsschematas erzeugen wird. Die Busmaster (Adressen und Da tenquellen) werden immer die Busanfrage aktivieren und auf die Bewilligung warten. NORMALERWEISE wird die Bewilligung in DEMSELBEN Zyklus auftreten wie die Anfrage, die davon ab hängt, ob der Bus nicht durch einen anderen Master/Slave be nutzt wird (alle Bewilligungen werden in Kombination er zeugt). Sobald die Busbewilligung durch den Master empfangen wird, werden den Adressen/Daten/Steuerungsleitungen der fol gende Zyklus gesendet. Ein "Daten-bereit"-Signal wird immer den aktuellen Daten vorgehen, um dem Empfänger anzuzeigen, das Verriegeln des folgenden Zyklusses zu beginnen.

Um die maximale Busbandbreite zu benutzen, können VIER (4) aufeinanderfolgende Anfragen in einer Pipeline-Rücken-an- Rücken-Anordnung empfangen/gesendet werden, und um alle vier Anfragen abzuarbeiten, wird ein "Anfrage-Fifo" benötigt. Die Speichersteuerungseinheit wird ein vier (4) tiefes Anfrage- Fifo und ein zwei (2) tiefes Daten-Fifo haben. Aufgrund die ser Natur des Protokolls wird ein "AF_FULL"- und ein "DF_FULL"-Signal benötigt werden. Sie sind: Adressen Fifo Voll bzw. Daten Fifo Voll. Die Fbus Datenbreite wird 8 Bytes (64 Bits) und eine Adresse von 32 Bits sein. Der Fbus wird die Datenübertragung von 8, 16 und 32 Bytes durch Benutzen der BewilligungsZÄHLER- und Req-Größen-Busse unterstützen.

Jede Fbus-Einheit wird die Steuerungslogik haben, um den Bus anzufordern. Diese Logik wird sich von Einheit zu Einheit un terscheiden, abhängig von den Anwendungen (Speicher/PCI/Cache . . . etc.). Jedoch wird die tatsächliche Busentscheidungsein heit in jeder Einheit dieselbe sein und wird in allen Unter modulen dupliziert werden. Diese Einheit wird als ein Medium zwischen den externen Mastern/Slaves und der internen Logik einheit agieren. Z.B. wird in dem Speichersteuerungsfall, so bald der CAS "aktiviert" abgefallen ist, die Speichersteue rungseinheit eine interne Anfrage an die Fbus- Arbitrationslogik über ein internes Signal aktivieren, das den Bedarf anzeigt, den Fbus zu benutzen. In Antwort auf die se Anfrage wird die Fbus-Steuerungseinheit eine Anfrage an das System aktivieren, extern zu der Speichersteuerungsein heitslogik, und auf die Bewilligung warten. Sobald die Bewil ligung empfangen wird, wird die Adressen/Daten/Steuerung von dem ersten Eingang des Antwort- und Daten-Fifos in die Spei chersteuerungseinheit gesendet werden.

Die Systemanfragen an die Speichersteuerungseinheit können irgendwo von 1 Byte bis zur maximalen Größe von 32 Bytes sein. Für die Anfragegrößen über 32 Bytes wird die Quelle/der Anfrager Mehrfachanfragen durch Benutzen der Fbus-"GRÖSSEN"- Bits initiieren. Dies wird aufgrund der Begrenzung des SDRAM Speicherbusses (1 oder 2 Samsung SDRAMS 1M×16) implemen tiert werden. Die SDRAMs werden für die Wrap-Länge von acht (8) programmiert werden, um die kompletten 32 Bytes zu errei chen, die vom Rest des Systems erforderlich sind. Für die An fragen, die weniger als 32 Bytes sind, werden ALLE 32 Bytes von dem SDRAM abgerufen werden, jedoch nur die gewünschte Zahl an Bytes wird zu dem Ziel ausgesendet werden.

Es wird ebenso einen zehn (10) Bit-Anfrager-ID-Bus geben, welcher mit dem "Chipauswahl"-Signal gültig sein wird (glei cher Zyklus wie Adressen/Daten).

Alle Fbus-Knoten werden eine 3 Bit-"Ziel-ID" an die Fbus- Entscheidungseinheit erzeugen. Diese drei Bits werden mit der Anfrage gültig sein und zeigen das Ziel der Anfrage an. Die Ziel-ID-Bits [1 : 0] werden von der ankommenden Anfrager-ID wie folgt decodiert:

Das Ziel-ID-Bit [2] wird benutzt, um den LESE/SCHREIB- Anfragestatus anzuzeigen. Dies wird der Fbus- Entscheidungseinheit helfen, zwischen den Nur- Adressenanfragen (lesen) und den Adressen/Datenanfragen (schreiben) zu differenzieren.

Normalerweise zeigen die Bewilligungszählbits "grCNT[1 : 0]" die Anzahl der Fbus-Zyklen an, für die der Anfrager den Bus benötigt. Für aufeinanderfolgende Anfragen werden die Anfra gen dem Busmaster die Länge der Anfragen anzeigen. Die Fbus- Mastersteuerungseinheit wird die Bewilligungen entsprechend den zwei Bewilligungszählbits aktivieren.

Der Fbus ist ein gesplitteter Transaktionsbus, welcher einge tragene Lesevorgänge unterstützt. Dies bedeutet, daß der An frager den Bus anfragt und sobald dieser bewilligt wird, wird er die Adresse eintreiben und die Transaktion beenden. Ir gendwann später wird die Slave-Einheit/Datenquelle die Daten durch Benutzung der Ziel-ID und durch Zurückgeben derselben Anfrage (112) an den Anfrager zurückgeben. Dieses Merkmal ver bessert die Busbandbreite entscheidend und erlaubt anderen Mastern, den Fbus schneller zu benutzen.

Bitte beziehen sie sich auf die Zeitsteuerungsdiagramme für nähere Details.

4.2 Pinbeschreibung

Das Folgende sind Adressen-, Daten- und Steuerungssignale des Systems Fbus. Wie vorher erwähnt, ist der Fbus NICHT ein mul tiplexierter Adressen/Datenbus.

"xxx" ist ein Drei-Buchstaben-Code, der den Anfragernamen an zeigt (mem, pci, asc, ccu).

System Pbus Signaldefinition

Fig. 30 stellt den Speicherleseanfrage-Fbus-Fluß dar. Die Fig. 31 stellt den Speicherschreibeanfrage-Fbus-Fluß dar. Die Fig. 32 stellt den Master/Slave-"Nicht-Speicher"-Anfrage- Fbus-Fluß dar. Die Fig. 33 stellt die zentralisierte Fbus Entscheidungssteuerungseinheit dar.

Die Fig. 34-36 sind Fbus-Zeitsteuerungsdiagramme. Die Fig. 34 stellt die Speicherschreibeanfrage-Fbus-Zeitsteuerung dar. (8 Byte-Datenübertragung wird gezeigt. Für 16/32/64/128 Bytes werden Mehrfachdatenzyklen benutzt.) Die Fig. 35 stellt die Speicher-reqd-Anfrage-Fbus-Zeitsteuerung (Übertragungsgröße = 8 Bytes) dar. Die Fig. 36 stellt die Speicher-Rücken-an- Rücken-Schreibeanfragen dar (Übertragungsgröße 32 Bytes).

Kapitel 5 PCI-Bus

Diese Kapitel beschreibt die Spezifikation des PCI KERNES und der PCI Randlogik, die mit den internen FBUS Schnittstellen bilden.

5.1 Überblick

Die MSP-IE PCI Steuerungseinheit ist so konstruiert, um der PCI Busbeschreibung, Revision 2.1 zu entsprechen. Bitte be ziehen sie sich auf diese Standardbeschreibung für nähere De tails.

Die PCI-Einheit enthält zwei Hauptabschnitte: den PCI Kern und die FBUS Randlogik. Der PCI Kern bildet hauptsächlich mit den externen PCI Vorrichtungen Schnittstellen, die bei einer PCI Busgeschwindigkeit laufen, welche 33 MHz ist. Die FBUS Randlogik bildet mit dem Samsung FBUS eine Schnittstelle, welche bei 80 MHz laufen wird. Diese Randlogik bildet die Schnittstelle zwischen dem PCI Kern und dem FBUS. Die Ge schwindigkeitssynchronisation wird durch Benutzen von Fifos an beiden Enden der Unterblöcke erreicht.

Der Samsung PCI Kern enthält ebenfalls die Virtual- Rahmenpufferlogik und alle VFB Register, die erforderlich sind, um mit dem ARM7 über den Fbus Schnittstellen zu bilden.

Ein spezielles Merkmal, welches einmalig bei dieser PCI Ein heit ist, ist die Unterbrechungshandhabung von dem Hauptrech ner CPU MSP Chip und dem MSP Chip zu der Hauptrechner-CPU. Dies wird im weiteren in diesem Kapitel diskutiert werden.

5.1.1 SAMSUNG PCI KERN Blockdiagramm wird in Fig. 37 ge zeigt.

5.2 PCI FBUS SCHNITTSTELLENLOGIK (Fig. 38)

Dieser Unterblock des PCI Kernes bildet Schnittstellen mit dem internen MSP FBUS und dem SAND Mikro PCI Kern. Die Adres sen und Daten werden in den FIFO an beiden Enden gespeichert (d. h., von dem PCI Kern und dem FBUS). Dieser Unterblock ist ebenfalls für das Synchronisieren der PCI Signale mit dem FBUS Takt und umgekehrt verantwortlich.

Die PCI Kernlogik kann eine FBUS Master-und Slave-Vorrichtung sein. Die meisten der Zugriffe werden an den lokalen SDRAM Speicher über den 64 Bit FBUS gerichtet werden. Bitte bezie hen sie sich auf das FBUS Kapitel zur Beschreibung des FBUS Protokolls.

Die PCI FBUS Steuerungslogik enthält ebenfalls die Register und Steuerung für die virtuellen Rahmenpuffer. Diese Register werden durch die ARM7 über den FBUS programmiert. Bitte be ziehen sie sich auf die Blockdiagramme.

5.3 PCI VFB LOGIK

Fig. 39 ist ein VFB Blockdiagramm. Fig. 40 zeigt VFB Regi ster.

5.4 PCI KERNLOGIK

Der MSP PCI Kern ist entsprich komplett den PCI 2.1 Spezifi kationen. Der einzige Zusatz, der gemacht wird, war die An zahl der Register, die zum Unterbrechen und zum softwaremäßi gen MSP Rücksetzen hinzugefügt wurden.

Die Software in dem ARM7 kann die HAUPTRECHNER CPU durch Set zen der PCI Hauptrechnerunterbrechungsanfrage von dem MSP (Bit<3<) des MSP Steuerungsregisters unterbrechen. Dies wird die PCI Kernlogik dazu veranlassen, die Hauptrechner CPU durch Aktivieren des Unterbrechungs-Pins in dem PCI Bus (INTA#) zu unterbrechen. Die Hauptrechner-CPU wird dann die Unterbrechung durch die PCI Hauptrechnerunterbrechungsbestä tigung (Bit<4<) in dem MSP Steuerungsregister bestätigen. Dies wird die Unterbrechungsleitung dazu veranlassen, in ei nen inaktiven Zustand überzugehen.

Der MSP CI Kern kann ebenso eine Unterbrechung von der Hauptrechner-CPU akzeptieren, welche grundsätzlich eine Un terbrechung an die ARM7 ist. Da die PCI Spezifikation nicht alle Unterbrechungseingangspins unterstützt, wird die MSP Un terbrechungsanfrage vom Hauptrechner (Bit<2<) in dem MSP Steuerungsregister benutzt, um diese Funktion vorzusehen. Die Hauptrechner-CPU kann dieses Bit setzen, um eine Unterbre chung für die ARM7 zu initiieren. Die ARM7 wird dann dieses Register löschen, sobald die Hauptrechnerunterbrechung bestä tigt wird. Siehe das Blockdiagramm in Fig. 41. Mit Bezug auf die Fig. 41 benötigen wir drei Register, die in den MSP Be reich und nicht in den PCI Raum abgebildet werden.

Um detaillierte Informationen über den eigentlichen PCI Kern zu bekommen, bitte beziehen sie sich auf die PCI 2.1 Spezifi kation.

Kapitel 6 Speichersteuerungseinheit

6.1 Dieses Kapitel beschreibt die Spezifikation der Spei chersteuerungseinheit, wie sie durch die Hardware- und Soft ware-Konstrukteure gesehen wird.

6.2 Überblick

Die MSP Speichersteuerungseinheit wird eine Vielzahl von Merkmalen und Programmierbarkeits-Niveaus für Kosten und Lei stungskompromisse haben. Die Speichersteuerungseinheit wird zwischen dem Hauptsystembus "Fbus", welcher bei 80 MHz laufen wird, und den DRAM Chips Schnittstellen bilden. Um die 80 MHz-Taktfrequenzsynchronisation zu erreichen, werden DRAMS für den anfänglichen Aufbauschritt benutzt.

Schließlich wird das Speichersystem Standardschnellseiten DRAMS, erweiterte-Datenausgabe-(EDO)- DRAMS und den synchrone DRAMS unterstützen. Die Speicherbankgröße wird auf zwei (2) externe Bänke begrenzt werden, welche verschachtelbar sein werden.

Die anfängliche Synchronisations-DRAM- Speichersteuerungseinheit wird bloß die minimalen Merkmale haben, die erforderlich sind, um den DRAMS zu betreiben. Das folgende sind die "grundlegenden" erstgradigen Speicher- Steuerungseinheitsmerkmale:

- Unterstützung der synchronen DRAMS von Samsung;
- eine (1) Speicherbank, die zwei SDRAM Chips (1M×16) be nutzt;
- Unterstützung von Cas-Bevor-ras Wiederauffrischung (CBR)
- Unterstützen von Teilschreiben, das Lese-Modifizierungs- Schreibe-Operationen initiiert;
- Unterstützen von interner Bankverschachtelung (Pingpong über MA[11]);
- 80 MHz Speicher und Prozessorbus (1 : 1) Frequenzanpas sung;
- programmierbare Auffrischrate;
- Adressen- und Datenwarteschlange, um besser den System bus zu nutzen;
- Unterstützen von manueller "Voraufladung von beiden Bän ken".

Die MSP Speichersteuerungseinheit wird zwei Hauptunterkompo nenten haben: die Datensteuerungseinheit und die Adressen steuerungseinheit. Die Datensteuerungseinheit wird die Daten warteschlangen lesen und schreiben, um die Lesedaten von dem DRAM und die Schreibendaten von dem Prozessorbus zu spei chern. Die Datensteuerungseinheit wird ebenso die gesamte RMW Logik für das Byte-Schreiben enthalten. Alle Steuerungen an die Datensteuerungseinheit werden von der Adressensteuerungs einheit erzeugt.

Die Adressensteuerungseinheit wird die Anfragewarteschlange, die Antwort-ID-Warteschlange, die Speicheradressendecodie rungslogik, die Seitenkomparatorlogik, die RAS/CAS Zustands maschine, die Auffrischungszustandsmaschine und alle notwen digen Steuerungssignale, die durch die Datensteuerungseinheit benutzt werden, haben.

Der SDRAM Speichertakt wird derselbe wie der Systemtakt sein. Der SDRAM wird eine Kopie von jedem der Steuerungssignale empfangen.

6.2.1 Speichersteuerungseinheits-Blockdiagramm wird in Fig. 42 gezeigt.

6.2.2 Der Speichersteuerungsfluß wird in Fig. 43 gezeigt.

6.3 Adressensteuerungseinheit (AC)

Der Adressensteuerungseinheitsabschnitt der Speichersteue rungseinheit wird für das Erzeugen aller DRAM Steuerungen als auch für das Managen der Datensteuerungseinheit verantwort lich sein. Dieser Abschnitt der MSP Speichersteuerungseinheit wird ebenso für den Adressen- und Steuerungsweg der Fbus Schnittstelle verantwortlich sein. Das folgende Blockdiagramm beschreibt die verschiedenen Unterabschnitte der Adressen steuerungseinheit.

6.3.1 Das Adressensteuerungsblockdiagramm wird in Fig. 44 gezeigt.

6.3.2 Speichersteuerungseinheitsanfrage Fifo

Die MSP Speichersteuerungseinheit wird vier tiefe Anfrage- Fifos haben, die alle Fbus Adressen und Steuerungsinformatio nen für ein späteres Verteilen an die eigentliche Speicher steuerungseinheits-Zustandsmaschine speichern wird. Jeder Eingang des Anfrage-Fifos wird ein "gültiges" Bit haben, um die Gültigkeit des besonderen Eingangs anzuzeigen. Die Spei chersteuerungseinheits-Zustandsmaschine wird immer den nied rigsten Eingang in dem Fifo, welche ENTRY_0 ist, abarbeiten. Sobald die Anfrage abgearbeitet ist und der Spaltenadressen abtastimpuls (CAS) abgefallen ist, wird die Speicherungs steuerungseinheit ein Löschungssignal aktivieren, um diesen Eingang zu löschen. Abhängig von dem Fifo VOLL (FULL)/LEER(EMPTY)-Status kann eine Bitstellenverschie bung eingeleitet werden, um die GÜLTIGKEITS(VALID)-Inhalte zum Eingang 0 zu verschieben.

Das MSP Speichersteuerungseinheits-Anfrage-Fifo-Format wird in Fig. 45 gezeigt.

6.3.3 Speichersteuerungseinheitsadressen-Decodierung/Liste

Die Adressendecodierungslogik wird hauptsächlich für das Er zeugen der SDRAM Zeilenadresse von 11 Bits MA[10 : 0] und der Spaltenadresse von 8 Bits MA[7 : 9] verantwortlich sein. Diese Adressenleitungen werden direkt zu den SDRAMS Adresseneingän gen [11 : 0] gesteuert. Das Speicheradressenbit [11] wird be nutzt, um zwischen den internen SDRAM-Bänken für die Lei stungsfähigkeit und bessere Speicherbusnutzung hin- und her zukippen.

Diese Speicheradresse wird durch Benutzen der programmierba ren Multiplexer erzeugt, welche über die Register gespeist werden, welche anzeigen:

- momentane Systemcache-Leitungsgröße
- Anzahl der internen Bänke
- interne Bankverschachtelung

Der Systemcache-Leitungsoffset wird fünf (5) Bits für die 32 Byte-Cacheleitung sein. Die Fig. 46 zeigt ein vorgeschla genes Speicheradressenformat, das von der Fbus Systemadresse für 16 Mbit DRAMs erzeugt wird.

Diese multiplexierte Speicheradresse wird für einen Zyklus mit RAS und CAS Abtastimpulsen gültig sein, die durch die Speichersteuerungseinheits-Zustandsmaschine angezeigt werden.

Die MCU hat die Fähigkeit, das 8 Byte-Schreiben ohne Initiie rung einer Lese-Modifizierungs-Schreibe-Operation durchzufüh ren. Jedoch sollte das Bit [2] der Fbus Adresse IMMER für ge rade Startadresse NUR Null sein. Dieses Bit beim Bit [0] der SDRAM Adresse abgebildet, welches eines der drei Bits ist, der die Startadresse wie folgt anzeigt:

Faddr [4:]	Schreibsequenz (WRAP = 8)
0 0 0	0-1-2-3-4-5-6-7
0 1 0	2-3-4-5-6-7-0-1
1 0 0	4-5-6-7-0-1-2-3
1 1 0	6-7-0-1-2-3-4-5

Dieses sind die Sequenzen, die durch die MCU unterstützt wer den, welche alle die gerade Startadresse haben.

Alle Lesefunktionen werden als 32 Byte xfers angenommen und die Startadresse sollte (000) = rna[2 : 0]=faddr[4 : 2] sein.

6.3.4 Speichersteuerungseinheits-Zustandsmaschine

Die MSP Speichersteuerungseinheit wird EINE Mastersteuerungs einheits-Zustandsmaschine haben. Diese Zustandsmaschine wird für das Erzeugen aller Zeitsteuerung für die SDRAM Steue rungssignale (RAS/CAS/WE/CS/DQM) verantwortlich sein. Die Zu standsmaschine wird konstant den Anfrage-Fifo auf einen gül tigen Eingang in dem Eingang(ENTRY) 0 überwachen. Sobald ein gültiges Bit detektiert wird, wird die Zustandsmaschine das Starten der SDRAM Sequenz anstoßen. Sie wird ebenso das Pa ge hit-Signal von dem Seitenkomparator überwachen, um zu be stimmen, wenn die RAS Vorladung benötigt wird.

Die RAS-Vorladung wird auf der aktuellen aktiven/offenen Bank durchgeführt. Die manuelle Vorladungssequenz beinhaltet das Aktivieren von CS, RAS, WE und MA[10] auf den aktiven Zu stand, welcher Null ist. Das interne Bankauswahlbit MA[11] wird benutzt werden, um die Bank zum Vorladen auszuwählen. Für die Lesefälle: Der Vorladungsbefehl wird, nachdem die Da ten von dem SDRAM empfangen worden sind, aktiviert, um Daten verstümmelung zu vermeiden. Für die Schreibefälle: Die Vorla dung wird ausgegeben werden, nachdem der letzte Schlag an Da ten in den Speicher geschrieben wurde. Sobald der Vorladungs befehl vollständig ist, wird diese besondere Bank in einem Leerlaufzustand sein, der für die nächste Speicherfunktion bereit ist. Entsprechend den SDRAM Spezifikationen kann der Vorladungsbefehl jederzeit ausgegeben werden, nachdem tRAS(min) genügt wurde (für diesen Fall sind 60 ns). Jedoch wird aufgrund unserer wrap-Länge von vier (4) die Speicher steuerungseinheits-Zustandsmaschine den Vorladebefehl ausge ben, NACHDEM die Daten an den Speicher gelesen/geschrieben worden sind.

Das Folgende zeigt die SDRAM Parameter, die mit der MSP Spei chersteuerungseinheit benutzt werden.

SDRAM Parameter

6.3.4.1 Zustandsmaschinendiagramm

Fig. 47 ist ein SDRAM Speichersteuerungs-RAS/CAS-Zustandsma schinendiagramm.

6.4 Speichersteuerungseinheits-Auffrischung

Die synchronen DRAMS müssen alle 32 ms (15,6 µs) aufgefrischt werden, um die Daten in jeder Speicherzelle zu halten. Die synchronen DRAMs unterstützen ebenso zwei Auffrischungsmodi: AUTO-AUFFRISCHUNG und SELBST-AUFFRISCHUNG.

6.4.1 SDRAM "Auto-Auffrischung"

Durch Benutzen der Standard AUTO Wiederholung werden beide interne Bänke abwechselnd durch einen internen Zähler aufge frischt. Da die Zahl der Zeilen 4096 ist, wird deshalb die Auto-Auffrischung 2048 Auto-Auffrischungszyklen erfordern, um den gesamten DRAM aufzufrischen.

Der Auto-Auffrischungsbefehl wird durch Aktivieren eines Niedrig auf CS,RAS & CAS mit einem Hoch auf CKE und WE ausge geben. Dieser Befehl wird nur aktiviert werden, wenn beide internen Bänke im Leerlaufzustand sind.¹
¹ Samsung SDRAM Spezifikation REV.5

Die Zeit, die für die komplette Auto-Auffrischung erforder lich ist, ist:

6.4.2 SDRAM "Selbst-Auffrischung"

Die Selbstauffrischung ist noch ein anderer Modus, der bei den Samsung SDRAMs verfügbar ist. Dies ist im allgemeinen der bevorzugte Auffrischungsmodus für Datenaufrechterhaltung und niedrigen Leistungsbetrieb. Hier werden die SDRAMS den inter nen Takt und alle Eingangspuffer mit Ausnahme des CKE ab schalten.

In den Selbstauffrischungsmodus wird eingetreten, wenn CS, RAS, CAS und CKE niedrig sind und WE hoch ist. Die SMP Spei chersteuerungseinheit wird NICHT diesen Auffrischungsmodus benutzen, da sie das Sperren des SDRAM Taktes erfordert und das Wiederstarten durch Benutzen des CKE Signales.

6.4.3 Manuelle Auffrischung

Diese dritte Wahl der Auffrischung erfordert eine Zustandsma schinen/Zähler-Aufbau. Der Zähler wird alle 15,6 µs zeitlich überwachen und einen Auffrischungsabtastimpuls an die Spei chersteuerungseinheitslogik anlegen. Die Speichersteuerungs einheit wird dann die laufende Anfrage beenden und sofort ei nen SDRAM Auffrischungszyklus initiieren. Dieser Zyklus wird exakt wie der Autoauffrischungszyklus aussehen, ohne die Ein schränkung zu haben, im LEERLAUF-Zustand zu sein.

6.5 Datensteuerungseinheit (DC)

Der Datensteuerungseinheitsabschnitt der Speichersteuerungs einheit wird hauptsächlich als Datenwarteschlange für Schreibdaten vom Prozessor oder Lesedaten vom SDRAM dienen. Diese Steuerungseinheit wird ebenso die Schreibemischungslo gik für alle Teilschreibfälle (Byte-Schreiben) haben. Anzu merken ist, daß das Teilschreiben einen DRAM dazu anstößt, zuerst zu lesen, dann die Daten zu vermischen und schließlich das komplett modifizierte Wort zurück zu dem Speicher zu schreiben. Deshalb wird jede Anfrage, die der Teilschreibese quenz folgt, den Leistungstreffer übernehmen müssen.

6.5.1 Das Datensteuerungseinheits-Blockdiagramm wird in Fig. 48 gezeigt.

6.6 Pinbeschreibung

Diese Steuerungseinheit trägt zu den folgenden Gehäusepins bei:

RAS_I Ausgangspin (aktiv niedrig). Dies sind die Zeilen adressen-Abtastimpulse, um die Zeilenadresse von MA[11 : 0] in dem ausgewählten internen Zeilenadres senpuffer der DRAM-Bank zu verriegeln bzw. zwi schenzuspeichern.

CAS_I Ausgangspin (aktiv niedrig). Dies sind Spalten adressenabtastimpulse, um die Spaltenadresse von MA[11 : 0] in dem ausgewählten internen Spaltenadres senpuffer der DRAM-Bank zu verriegeln bzw. zwi schenzuspeichern.

WE_I Ausgangspin (aktiv niedrig zum Schreiben). Um den Schreibfreigabeeingangspin des DRAM anzusteuern.

MA[11 : 0] Ausgangspins. Multiplexierte Zeilen-und Spalten adressensignale an den DRAM.

DQM Ausgangspin. Stellt die SDRAM Datenausgangshochim pedanz her nach dem Takt und maskiert den Ausgang. (Dieser Pin wird nur für synchrone DRAM Schnittstel len benutzt.)

CS_I Ausgabepin (aktiv niedrig). Um den ausgewählten SDRAM Betrieb ein- oder auszuschalten. (Dieser Pin wird nur für die synchrone DRAM Schnittstelle be nutzt.)

CLK Ausgangspin. Dies ist der Taktausgangspin nur zum synchronen DRAM. Es wird nur von dem SDRAM benutzt und hat dieselbe Phase wie der MSP Systemtakt.

6.7 Die Speichersteuerungseinheit-Zeitsteuerungsdiagramme werden in den Fig. 49-51 gezeigt. Anmerkungen bezüglich der Fig. 49:

- Es wird ein Samsung SDRAM angenommen.
- Der Speicher und das System laufen bei 80 MHz.
- Einen oder zwei externe (1M×16) SDRAMS.
- Programmierbare wrap(Deck-)-Länge von 4/8, um eine Lei tung von dem Speicher abzurufen.
- tRCD = 3.
- tCAS = 3.
- Interne Verzögerung = 2 Takte.
- Speicherungswartezeit = 8 Zyklen (8×12,5 = 100 ns)
- Systemdaten vom Speicher werden durch zwei Zyklen für Entscheidung (Lesedaten) verzögert werden:

6.8 Programmierungsmodell

Die Steuerungsregister, die in Beziehung mit der Speicher steuerungseinheit stehen, wie sie durch den Programmierer ge sehen werden, sind:

6.8.1 SDRAM RÜCKSETZ Register (R/W)

Dieses Register sollte nach jedem Systemzurücksetzen zurück gesetzt werden. Dies ist ein Ein-Bit-Register, das das re set_sdram-Signal überträgt, welches die SDRAM Leistungs-ein- Sequenz startet. Bei Systemrücksetzung wird dieses Register auf eins gesetzt. Die Software MUSS dieses Register löschen, um den SDRAM zu starten.

Bit 0 wird mit dem Systemzurücksetzen gesetzt und zu einem späteren Zeitpunkt gelöscht, um den SDRAM zu starten.
Programmierungsadresse
Faddr [31 : 20] = 12'h010
Faddr [3 : 0] = 4'b1011.

6.8.2 SDRAM Datenkettentypregister (R/W)

Dieses Register programmiert den SDRAM Datenketten(Burst)typ. Dies ist ein Ein-Bit-Register, welches auf NULL für einen SEQUENTIELLEN Datenkettentyp programmiert werden sollte.
Programmierungsadresse
Faddr [31 : 20] = 12'h010
Faddr [3 : 0] = 4'b1010
Bit 0 wird mit dem Systemzurücksetzen zurückgesetzt und zu einem späteren Zeitpunkt gesetzt, um den SDRAM zu starten.

6.8.3 SDRAM Auffrischungsregister (R/W)

Dieses Register programmiert den SDRAM AUFFRISCHUNGSWERT. Dies ist ein 12 Bit-Register, welches über den Fbus ebenso programmiert werden sollte.
Programmierungsadresse
Faddr [31 : 20] = 12'h010
Faddr [3 : 0] = 4'b1001
Bit 11-0 wird zurückgesetzt mit der Systemzurücksetzung und programmiert, um den Wert von 4E0 aufzufrischen.

6.8.4 SDRAM RAS VORLADUNGS (tRP) Register (R/W)

Dieses Register programmiert den SDRAM RAS VORLADUNGSWERT. Dies ist ein 3 Bit-Register, welches über den Fbus genauso programmiert werden sollte.
Programmierungsadresse
Faddr [31 : 20] = 12'h010
Faddr [3 : 0] = 4'b1000
Bit 2-0 wird mit dem Systemzurücksetzen zurückgesetzt und entweder auf 1 oder 2 oder 3 programmiert.

6.8.5 SDRAM CAS WARTEZEIT (tCAC) Register (PJW)

Dieses Register programmiert die SDRAM CAS Wartezeit. Dies ist ein 3 Bit-Register, welches über den Fbus ebenso program miert werden sollte.
Programmierungsadresse
Faddr [31:20] = 12'h010
Faddr [3 : 0] = 4'b0011
Das Bit 2-0 wird mit der Systemzurücksetzung zurückgesetzt und auf entweder 1 oder 2 oder 3 programmiert.

6.8.6 SDRAM RAS CAS VERZÖGERUNGS (tRCD) Register (R/W)

Dieses Register programmiert die SDRAM RCD Wartezeit. Dieses ist ein 3-Bit Register, welches über den Fbus ebenso program miert werden sollte.
Programmierungsadresse
Faddr [31 : 20] = 12'h010
Faddr [3 : 0] = 4'b0010
Das Bit 2-0 wird mit der Systemzurücksetzung zurückgesetzt und auf entweder 1 oder 2 oder 3 programmiert.

6.8.7 SDRAM WRAP LÄNGENREGISTER (R/W)

Dieses Register programmiert die SDRAM WARP LÄNGE für die DATEN. Dies ist ein 3 Bit-Register, welches ebenso über den Fbus programmiert werden sollte.
Programmierungsadresse
Faddr [31 : 20] = 12'h010
Faddr [3 : 0] = 4'b0001
Das Bit 2-0 wird mit der Systemzurücksetzung zurückgesetzt und auf entweder 1, 2, 4, 8 programmiert.

6.8.8 SDRAM NOP Zeitregister (R/W)

Dieses Register programmiert die SDRAM NOP ZEIT FÜR DIE LEISTUNGS-EIN-SEQUENZ. Dies ist ein 16 Bit-Register, welches über den Fbus ebenso programmiert werden sollte.
Programmierungsadresse
Faddr [31 : 20] = 12'h010
Faddr [3 : 0] = 4'b000
Bit 15-0 wird mit der Systemzurücksetzung zurückgesetzt und auf 200 µs abhängig von der Taktfrequenz program miert.

Kapitel 7 ASIC Schnittstelle

Dieses Kapitel beschreibt die Spezifikation der ASIC Schnitt stelleneinheit.

7.1 Überblick

Die ASIC Schnittstelleneinheit (Fig. 52) wird eine program mierbare 32 Bit-DMA, verschiedene Fifos und Steuerungsblocks haben. Der ASIC Schnittstellenblock wird Schnittstellen bil den zwischen: Hauptsystembus (FBUS), welcher bei 80 MHz be trieben wird, und den CODEC Schnittstellenblocks, welche Schnittstellen zwischen MSP, AD1843 (Ton, Telefon), KS0122 (Videoeinfang), KS0119 und den VGA Schnittstellen bilden wer den. Die momentane Annahme ist, all die CODEC Schnittstellen und die DMA Steuerungseinheit bei voller FBUS-Geschwindigkeit laufen zu lassen, um alle Synchronisationsprobleme zu vermei den.

Der Kunden-ASIC-Block wird drei Hauptabschnitte haben: Die Fbus Master/Slave-Schnittstelle, die MSP 8-Kanal DMA Steue rungseinheit und den eigentlichen CODEC. Die Daten werden von dem FBUS zu dem CODEC und zurück fließen. Jedoch werden die Adressen NUR von der DMA Steuerungseinheit erzeugt werden. Diese Adresse wird dann in der FBUS Schnittstellenlogik FBUS- abgebildet. Alle Schreibvorgänge von anderen FBUS Knoten wer den NUR sein, um die Register in dem CODEC Abschnitt zu pro grammieren. Der gesamte andere Verkehr sollte Leseantworten mit Größen- und ID-Information sein . . . bitte sehen sie zu der Fbus Beschreibung.

Das Folgende sind Merkmale für die ASIC Schnittstellenein heit:

- Unterstützen der 32-Bit Basis DMA Funktion (8 Kanäle - einer für jeden CODEC);
- zwei 4 tief×64-Bit Daten Fifo;
- ein 1 tief×52-Bit ANFRAGE FIFO;
- ein 2 tief×52-Bit ANTWORT FIFO;
- Unterstützen von Master/Slave für den FBUS und CODEC Schnittstellenblock;
- Unterstützen der internen Entscheidung für acht CODEC Schnittstellenblocks;
- Betriebsfrequenz: bis zu 80 MHz;
- Unterstützen des Zugriffes zwischen dem IO zu dem SPEICHER, dem SPEICHER zu dem IO;
- Unterstützen der CODEC Initialisierung;
- Unterstützen der höchsten Priorität für KANAL0, der für KS0119 benutzt wird;
- Unterstützen des speziellen Adressenbusses, um eine hohe Leistung für den KS0119 zu erreichen.

Diese Kundenschnittstellenlogik wird drei verschiedene CODECs unterstützen:

- Ton und Telefon CODEC (AD1843). Dieser CODEC wird zwei gerichtete 64 Bit-Datenbusse haben, welche mit der DMA Steuerungseinheit kommunizieren werden. (Kanal 4 → DAC1, Kanal 5 → DAC2, Kanal 6 → ADC links, Kanal 7 → ADC rechts).
- Video-Erfassungs-CODEC (KS0122). Dieser CODEC wird eben so einen zweigerichteten 64 Bit-Datenbus haben und ist dazu imstande, M → IO und IO → M Anfragen an die DMA (Kanal 2) zu initiieren.
- Video-Ausgangs-CODEC (KS0119). Dieser CODEC wird Daten von der Speicherungssteuerungseinheit direkt (Kanal 0) empfangen.

ASIC SCHNITTSTELLENBLOCK 7.2 Direktspeicherzugriff-(DMA-)Steuerungseinheit

Die DMA-Steuerungseinheit wird Register haben, die für Adres senerzeugung und -übersetzung benutzt werden. Diese DMA- Steuerungseinheit wird 8 unabhängige Kanäle haben. Jeder Ka nal wird ein Aktuelles Adressenregister und ein Stopp- Adressenregister haben. Die Start- und Stopp-Adressenregister werden über den Konfigurationsblock vorprogrammiert sein. Das aktuelle Adressenregister wird geladen werden, wann immer es eine DMA-Anfrage von einem der acht CoDECs gibt. SOBALD der Fbus den Zugriff erteilt, wird diese DMA-Adresse jeden Zyklus inkrementieren, bis die aktuelle Adresse mit dem Stopp- Adressenregister übereinstimmt. Zu dieser Zeit wird die DMA- Steuerungseinheit ein Signal "EOP" (Ende des Prozesses) er zeugen. Dieses Signal wird eine Unterbrechung des Prozesses veranlassen. Alle acht DMA-Kanäle werden eine gemeinsame Ent scheidungseinheit haben, welche die Multiplexer und die Adressenvergleichsblöcke steuert.

Diese DMA-Steuerungseinheit wird den Zugriff zwischen der IO auf den SPEICHER, dem SPEICHER auf die IO und dem SPEICHER zu dem SPEICHER unterstützen. Wann immer ein CODEC mit der DMA kommunizieren muß, wird er ein DMA_REQ Signal aktivieren und auf die DMA-Bestätigung "DACK" von der DMA warten. SOBALD die Bestätigung da ist, wird er die M-IO Steuerungssignale und die Daten steuern. Die DMA-Steuerungseinheit wird den passen den Kanal auswählen, abhängig von der erteilten DACK.

Bitte betrachten Sie auch das Blockdiagramm.

7.3 DMA-Registerbeschreibung 7.3.1 Momentanadressenregister

Jeder Kanal hat ein 29 Bit Momentanadressenregister (Bits <31 : 3<), welches erfordert, daß alle Adressen 8 Byte- ausgerichtet werden. Eigentlich ist dieses Register ein 29 Bit-Zähler. Dieses Register kann durch die ARM7 gelesen wer den. Der Anfangswert wird von der ARM7 durch den FBUS gela den. Diese Adresse wird basierend auf der Datenübertragungs größe inkremetiert werden. Die Adresse in dem Momentanadres senregister wird an den Adressenerzeugungsblock gesendet wer den, um die Adresse auf den FBUS durch den Multiplexer zu la den. Das Momentanadressenregister wird den Adressenwert wäh rend des Leerlaufzustandes halten.

7.3.2 Stopp-Adressenregister

Jeder Kanal hat ein 29 Bit-Stopp-Adressenregister (Bits<31 : 3<), welches erfordert, daß alle Adressen 8 Byte- ausgerichtet sind. Dieses Register wird durch die ARM7 über den FBUS beschrieben. Diese Werte werden benutzt, um mit der aktuellen bzw. momentanen Adresse in dem Vergleichsblock ei nen Vergleich vorzunehmen. Wenn die aktuelle Adresse mit der Stopp-Adresse übereinstimmt, dann wird die DMA Steuerungsein heit ein Signal "EOP" für jeden Kanal erzeugen.

7.3.3 Statusregister

Dieses Register enthält Informationen, ob jeder Kanal er reicht hat, die Adresse zu stoppen oder nicht. Die Bits<7 : 0< beschreiben, welcher Kanal erreicht hat, die Adresse zu stop pen, sie wird zurückgesetzt werden, wenn die ARM7 das Momen tanadressenregister über die CCU initialisiert.

Dieses Register kann durch die ARM7 gelesen werden, jedoch kann die ARM7 nicht dieses Register beschreiben.

7.3.4 Steuerungsregister

Dieses Register enthält Steuerungsinformation für den Betrieb der DMA-Steuerungseinheit. Die Bits<7 : 0< beschreiben, welcher DMA-Kanal für den Betrieb eingeschaltet ist. Diese Bits wer den zurückgesetzt, wann immer der korrespondierende Kanal die Stopp-Adresse erreicht, und die ARM7 kann diese Bits setzen, um den Betrieb wieder zu starten. Wenn jedes Kanaleinschalt bit "0" ist, so wird die DMA nicht das DMA_ACK an den korre spondierenden CODEC geben, sogar wenn der CODEC das DMA_REQ an die DMA sendet. Die Bits<19 : 16< beschreiben, welches Paar an DMA-Kanälen hintereinander verbunden wird, um einen Dop pelpuffer auszuführen. Z.B., wenn der Kanal0 und der Kanal1 zusammen als ein Doppelpuffer verbunden werden, dann wird die DMA-Steuerungseinheit automatisch auf den Kanal1 schalten, wenn die aktuelle Adresse des Kanals0 seine Stopp-Adresse erreicht, und auf Kanal0 schalten, wenn die aktuelle Adresse des Kanals1 seine Stopp-Adresse erreicht. Das Bit <28 : 21< ent hält Informationen mit Bezug auf den Lese/Schreibemodus für jeden Kanal. Wenn jedes Bit von ihnen auf "1" durch die ARM7 gesetzt wird, wird der korrespondierende Kanal für die LESE- Funktion benutzt werden. Andere werden für die SCHREIB- Operation benutzt werden. Das Bit<31< beschreibt, ob die DMA ein EOP-Signal an die Unterbrechungssteuerungseinheit aussen det oder nicht. Wenn dieses Bit "0" ist, so wird die DMA nicht ein EOP aussenden, sogar wenn jeder Kanal die Stopp- Adresse erreicht hat.

7.3.5 Maskierungsregister

Jedem Bit in dem Steuerungsregister ist ein Maskierungsbit in dem Maskierungsregister zugeordnet. Wenn das Maskierungsbit "0" ist, dann verhindert es, das korrespondierende Bit in dem Steuerungsregister zu aktualisieren. Anfänglich wird dieses Register <31 : 0< auf Ffffffff(hex) gesetzt werden.

7.3.6 Programmierung

Die Start- und Stopp-Adresse wird durch die ARM7 über den FBUS programmiert.
FBUS abgebildete Werte sind wie folgt:
CCU → 0040_0000 - 007F_FFFF,
MCU → 0080_0000 - 047F_FFFF,
PCI → 0800_0000 - FFFF_FFFF.

Für Adressenprogrammierung sollte die Adresse[26 : 0] basierend auf der Tabelle 18 festgesetzt werden.

DMA-Registeradressenabbild

Codierung des Statusregisters

Codieren des Steuerungsregisters

7.4 CODEC Initialisierung

Die Kunden-ASIC-Einheit wird die Initialisierung für jeden CODEC unterstützen. Gegenwärtig sorgt die ARM7 für die CODEC Initialisierung durch die Kunden-ASIC-Einheit.

Die Kunden-ASCI-Einheit wird einen Adressendecodierer zum Er zeugen des Anfragesignales für jeden CODEC haben. Wann immer die Kunden-ASIC-Einheit mit einem CODEC sprechen muß, wird sie das Anfragesignal an den CODEC senden und auf das BESTÄ- TIGUNGSsignal von der CODEC warten. Nach Empfangen des BESTÄ- TIGUNGSsignals wird die Kunden-ASIC-Einheit Daten und Adres sen an die CODEC senden.

Wenn die ARM7 die Konfigurationsdaten in irgendeinem CODEC durch die CCU lesen will, so wird die Kunden-ASIC-Einheit die Adresse an den CODEC senden. Wenn die Kunden-ASIC-Einheit Da ten von dem CODEC empfängt, wird sie TRANSAKTIONS-IX) zurück an die CCU senden. Zu diesem Zeitpunkt werden die Konfigura tionsdaten an die ARM7 durch die CCU gesendet werden.

CODEC Konfigurationsregister FBUS Adressenabbild

Fig. 53 stellt die Kunden-ASIC-Schaltung dar.

4. I/O Pindefinition

I/O Pindefinition für die Kunden-ASIC-Einheit

Kapitel 8 AD1843 CODEC Schnittstelle

8.1 Dieses Kapitel beschreibt die AD1843 CODEC Schnittstel le.

8.2 Überblick

Der AD1843 CODEC Schnittstellenblock ist für die Schnittstel le zwischen dem AD1843 Serienbus und dem MSP DMA Modul. Der AD1843 sendet und empfängt sowohl die Daten als auch die Steuerung/Statusinformation über seine seriellen Anschlüsse. Der AD1843 hat 4 Pins, die ganz für die serielle Schnittstel le da sind: SDI, SDO, SCLK, SDFS. Der SDI Pin ist für den se riellen Dateneingang an den AD1843 und der SDO Pin ist für den seriellen Datenausgang von dem AD1843. Der SCLK Pin ist der serielle Schnittstellentakt.

Die Kommunikation in und aus dem AD1843 erfordert, daß die Datenbits nach einer ansteigenden Kante des SCLK gesendet und bei einer abfallenden Kante des SCLK abgetastet werden. Der SDFS Pin ist für die serielle Schnittstellenrahmensynchroni sation. Die AD1843 CODEC Schnittstelle basiert auf dem Ma stermodus. Dies bedeutet, daß das SCLK und das ADFS Signal durch den AD1843 erzeugt werden. Die Standard SCLK Frequenz wird 12,288 MHz sein und ein Rahmenzyklus wird 48 KHz sein.

Die Basisarchitektur für die CODEC Schnittstelle basiert auf DMA. Die AD1843-Schnittstelle ordnet 4 verschiedene DMA- Kanäle zu: Kanal 4 zu DAC1, Kanal 5 zu DAC2, Kanal 6 zu ADC links und Kanal 7 zu ADC rechts. Die Größe der Kanalübertra gung an oder von der DMA beträgt 64 Bits bei einem Mal. Des halb sendet der DMA-Kanal 4 und der DMA-Kanal 5 zwei ver schiedene 32 Bits Daten - 16 Bits für links und 16 Bits für rechts - vom SDRAM an die CODEC Schnittstelle. Andererseits senden die DMA-Kanäle 6 und 7 vier verschiedene 16 Bit-Daten bei einem Mal von der CODEC Schnittstelle an den SDRAM.

Die DAC1 und DAC2 Schnittstelle ist verfügbar, wenn das Mar kierungsbit von jedem Kanal gesetzt wird. Die DAC1 und DAC2 Schnittstelle fordert DMA an, nachdem das Markierungsbit überprüft wurde. Wenn das Markierungsbit zurückgesetzt wird, so erzeugt die DAC1 und DAC2 Schnittstelle nicht die DMA- Anfrage. Die eigentliche Funktion des Markierungsbits wird durch den DMA-Block gesteuert. Der DMA-Block erzeugt nicht das DMA-Bestätigungssignal, wenn das Markierungsbit zurückge setzt ist. Wenn der FIFO des ADC links und rechts nicht voll ist, so wird die DMA-Anfrage nicht erzeugt werden. Die Soft ware sollte das ADC-Markierungsregister überprüfen und die verbleibenden Daten über den Datenbus lesen. Nach dem Lesen solcher Daten über den Datenbus ist der FIFO leer und erzeugt die DMA-Anfrage, wenn der FIFO voll ist.

Die AD1843-Steuerungsregister werden durch Senden eines Le se/Schreibe-Anfragebits zusammen mit der Steuerungsregister adresse in den Steuerworteingang gelesen und geschrieben. Wenn ein Lesen angefragt wird, werden die Inhalte des Steue rungsregisters, das adressiert wird, während des folgenden Rahmens ausgesendet werden. Wenn ein Schreiben angefragt wird, so müssen die Daten, die zu schreiben sind, auf den Schlitz 1 des AD1843 gesendet werden. Zum Verbessern der Lei stung des MSP sollte der Programmierer das Steuerungsmarkie rungsregister überprüfen, bevor das Steuerungsregister in den CODEC gelesen oder geschrieben wird. Wenn das Markierungsbit des Steuerungsmarkierungsregisters gesetzt ist, so ist die Lese-und Schreibeoperation für das CODEC Register verfügbar.

8.3 DMA Kanalzuordnung

DMA Kanal

4

DAC1 links, rechts
DMA Kanal

5

DAC2 links, rechts
DMA Kanal

6

ADC links
DMA Kanal

7

ADC rechts

8.4 Datenformat zu und von der DMA

Die Datenübertragung enthält 64 Bit, die wie folgt organi siert sind:

8.5 Basisadressen

04C0_4000 DAC1 BASE
04C0_5000 DAC2 BASE
04C0_6000 ADCL BASE (Linker Kanal)
04C0_7000 ADCR BASE (Rechter Kanal)

8.6 Registerabbild

8.7.1 Steuerungsregister-Schreibedateneingang

Das höchstwertige Bit (MSB) ist das erste zu übertragende Da teneingangsbit.

8.7.2 Steuerungsworteingang

l/s Lese/Schreibeanfrage. Entweder ein Lesen vom oder ein Schreiben an ein Steuerungsregister tritt bei jedem Rahmen auf. Das Setzen von "1" zeigt ein Steuerungsregister-Lesen an, während das Zurückset zen dieses Bit auf "0" ein Steuerungsregister- Schreiben initiiert.

ia4 : 0 Steuerungsadressenregister für Lesen oder Schrei ben.

8.7.3 Steuerungsregisterdatenausgang

Die Inhalte des Steuerungsregisters, das im vorherigen Rahmen adressiert wird.

8.7.4 ADC Markierungsregister

r4v-rlv Gültige ADC rechte Daten sind in dem Puffer. Zeigen an, welche Daten in dem Puffer verfügbar sind.

l4v-11v Gültige ADC linke Daten sind in dem Puffer. Zeigen an, welche Daten in dem Puffer verfügbar sind.

8.7.5 ADC Links 1. Daten

ADC Links erste Daten in dem Puffer.

8.7.6 ADC Links 2. Daten

ADC Links zweite Daten in dem Puffer.

8.7.7 ADC Links 3. Daten

ADC Links 3. Daten in dem Puffer.

8.7.8 ADC Links 4. Daten

ADC Links 4. Daten in dem Puffer

8.7.9 Steuerungsmarkierungsregister

wfl Steuerungsregister-Schreibemarkierung. Wenn gesetzt, so ist der CODEC bereit zum Empfangen der Kontrollregister daten.

rfl Steuerungsregister-Lesemarkierung. Wenn gesetzt, so ist der CODEC bereit zum Senden der Steuerungsregisterdaten.

Kapitel 9 Video Codec 9.1 Überblick

Die Video-CODEC-Logik bildet Schnittstellen an die KS0119 und KS0122 Chips auf der Auswertungsleiterplatte und bildet Schnittstellen an das DMA Modul in dem MSP Chip. Der KS0119 CODEC kann ebenso eine Bildschirmauffrischfunktion liefern. Für diese Funktion wird ein direkter Datenweg an das MCU Mo dul implementiert, wie in Fig. 54 gezeigt.

9.2 TOP MODUL DEFINITION

Das Top-Modul enthält 3 Untermodule, wie in Fig. 55 gezeigt:

- das KS0119 Bildschirmauffrischungsmodul,
- das KS0122 Video-Daten-Erfassungsmodul und
- das serielle Hauptrechnerschnittstellenmodul mit 3 Lei tungen, das auf die KS0199 und KS0122 Chip- Konfigurationsregister zugreift.
9.3 DMA Kanal-Zuordnungen

9.4 Drei-Leitungs-Hauptrechnerschnittstellenmodul

Dieses Modul bildet Schnittstellen mit den KS0119 und den KS0122 Chips, wobei auf alle Register innerhalb dieses Chips über die serielle Schnittstelle zugegriffen wird. Das seriel le Schnittstellenmodul mit 3 Leitungen unterstützt die Funk tionen des Kommunikationsprotokolles an die Chips und enthält die Register für die KS0119 und KS0122 Schnittstellenlogik. Bitte beziehen sie sich auf Fig. 3.

9.5 EPROM Schnittstelle

Die KS0119 10 Pins werden ebenfalls als Schnittstelle an ei nen externen EPROM benutzt, welcher benutzt wird, um die Pro grammdaten unmittelbar nach dem Systemrücksetzen zu laden, und ein Teil der MSP-1EX Boot-Initialisierung ist. Bitte be ziehen sie sich auf die Pin-Zuordnung für nähere Details.

Der EPROM ist speicher-zugeordnet, mit den Adressenbereichen von CO 000H bis DF FFFH.

9.6 KS0119 Registerbeschreibung

Der KS0119 hat eine Basisadresse CODEC_REQ0, die gleich 04B0 0000 ist und sich bis 04BF FFFF erstreckt.

9.6.1 KS0119 Registeradressenabbild

KS0119 Registeradressenabbild

9.6.2 Rahmengrößenregister

Dieses Register steuert die Rahmengröße, die an den CODEC Chip zu senden ist, wie es in Fig. 57 definiert wird. Die mi nimale Rahmenlänge ist 3 Byte.

9.6.3 Chip ID Register

Dieses Register sollte den CODEC Chip ID Wert enthalten und sollte 03H für KS0199 Schreiben und 83H für KS0119 Lesen ent halten.

9.6.4 Steuerung/DATENregister

Dieses Register informiert den CODEC Chip KS0119, daß das folgende gesendete BYTE ein Register-INDEX oder ein DATEN- Byte sein wird. Für KS0119 = 08H bedeutet dies, daß INDEX das folgende Byte ist und 09H bedeutet, daß DATEN das folgende Byte sind.

9.6.5 INDEX/DATEN0 Register

Dieses Register wird den INDEX-Wert für das CODEC-Chip- Konfigurationsregister oder das DATEN0-Byte abhängig von dem Wert, der in dem vorherigen Byte gesendet wird, enthalten.

Bitte beziehen sie sich auf das Kommunikationsprotokoll in dem Programmier-Referenzabschnitt

9.6.6 DATEN1 Register

Dieses Register enthält die Daten, die in das CODEC Register, Index + 1 zu schreiben sind.

9.6.7 DATEN2 Register

Dieses Register enthält die Daten, die in das CODEC Register zu schreiben sind, Index + 2.

9.6.8 DATEN3 Register

Dieses Register enthält die Daten, die in das CODEC Register zu schreiben sind, Index + 3.

9.6.9 KS0119 Logisches Steuerungsregister

Diese Bitzuordnungen für das KS0119 Steuerungsregister werden in Fig. 58 gezeigt.

9.6.10 HS und VS Polarität

Dieses Register definiert die Polarität des Horizontalen Sync- und des Vertikalen Sync-Signales. Ein Wert von 0 wird definiert, um aktiv NIEDRIG zu sein, wohingegen ein Wert von 1 definiert wird, um aktiv HOCH zu sein. Die Bitzuordnung ist wie folgt:
Bit <0<: VS Polarität
Bit <1<: HS Polarität

9.6.11 HS Offset

Das aktive Signal wird nach diesem Offset-Wert erzeugt. Es wird zu 00H definiert.

9.6.12 VS Offset

Das aktive Signal wird nach diesem Offset-Signal erzeugt. Es wird zu 00H definiert.

9.6.13 Statusregister wird in Fig. 59 gezeigt.

9.6.14 Serielles Schnittstellenregister für Lese-DATEN

Dieses Register wird die gültigen Daten von dem seriellen An schluß enthalten, nachdem die Lesemarkierung den Übergang von dem besetzen auf den bereiten Zustand gemacht hat.

9.6.15 Lese-PROM-Datenregister

Dieses Register wird die gültigen PROM Daten enthalten, wenn die PROM Markierung in dem Bereit-Zustand ist.

9.6.16 PROGRAMMIERUNGSREFERENZ 9.6.16.1 Konfiguration und Initialisierung

Die Video-Anzeige-Hardware kann konfiguriert werden, um in zwei verschiedenen Modi zu funktionieren:

- VGA Überlagerungsmodus.
- VGA Emulationsmodus.

Diese Modusfunktion wird durch das Setzen eines Bits in dem logischen Steuerungsregister gesteuert.
MSSEL = 0 für VGA Überlagerungsmodus,
= 1 für VGA Emulationsmodus.

In dem VGA Überlagerungsmodus ist die Existenz einer VGA Kar te in dem PC System erforderlich.

- Das Monitorkabel wird mit der MSP-Karte verbunden.
- Die VGA-Auflösungen werden bis zu 800×600 unterstützt.
Der Anzeigepuffer muß in derselben Größe wie die VGA- Festsetzungen sein.

Um ein Video-Fenster zu setzen, sollte die Software ein Farbschlüssel-Rechteckgebiet in dem VGA Rahmenpuffer füllen, wobei die Video-Daten in dem MSP SDRAM in ein rechtwinkliges Gebiet von derselben Größe und der Anordnung des rechtwinkli gen Gebietes in dem VGA Rahmenpuffer geschrieben werden soll ten. Bezug wird auf Fig. 60 genommen.

Der KS0119 Chip wird den Farbschlüssel erkennen und von dem VGA Eingangsanschluß zu dem Video-Eingangsanschluß schalten. Die Software sollte die Startadresse des DMA Kanals 0 an der oberen linken Ecke des SDRAM Video-Ausgangspuffers setzen, wobei die DMA Aufzeichnungslänge entsprechend der Auflösung der VGA Karte und dem Bit pro Pixel, die in den Video-Daten benutzt werden (4 : 2; 2 = 16 Bit pro Pixel), festgesetzt wer den sollte.

9.6.16.2 Serielle Protokoll-3-LEITUNGS-Schnittstelle an KS0119

Beim Festsetzen der Konfigurationsregister in dem KS0119 Chip ist das Protokoll wie folgt festgelegt:

- Ein Minimum von zwei Rahmen muß zu den peripheren Chips gesendet werden,
- der erste Rahmen soll den Index des Konfigurationsregi sters setzen,
- der zweite Rahmen ist zum Lesen und Schreiben der Daten (Inhalt des Registers).

Die Software sollte das Rahmengrößenregister auf die geeigne te Länge festsetzen und das serielle Zugriffsbit = 1 setzen. Dann sollte die Software alle Bytes laden, die für den Rahmen erforderlich sind, bevor das Rahmengrößenregister verändert wird, wobei die CODEC Schnittstellenlogik warten wird, bis alle Bytes geladen sind, bevor das Serialisieren des Rahmens startet.

Das erste, das gesendet wird, soll den Index festsetzen. Die Rahmengröße = 3 Bytes. Es wird Bezug auf Fig. 61 genommen.

Der zweite Rahmen soll das Register setzen. Rahmengröße = 3.

Nach jedem Datenbyte wird das Chip den Index um Eins auto inkrementieren, welches ermöglicht, die aufeinanderfolgenden Register durch Senden von Mehrfachbytes an Daten zu setzen, wobei die CODEC Schnittstellenlogik bis zu vier Datenbytes unterstützt.

Wenn eine serielle Lese-und Schreib-Operation durchgeführt wird, so sollte die SOFTWARE die Lese-und Schreibemarkierung des Statusregisters für gültige DATEN in dem Lesebetrieb oder die Schreibmarkierung = bereit, bevor der nächste Rahmen ge sendet wird, überprüfen.

Das folgende Beispiel zeigt Schritt um Schritt das Setzen des KS0119 Konfigurationsregisters.

Um den Wert des Chroma-Schlüssel-Byte 0 und -Byte I zu set zen, ist der Index für dieses Register 6AH für Byte 0 und 6BH für Byte1, mit Bezug auf die KS0119 Datenblätter.

Da die zwei Register einen fortlaufenden Index haben, können diese zwei Bytes in einem Einzelrahmen geladen werden. Zuerst muß der Index wie folgt festgesetzt werden:

- Lade das Rahmengrößenregister (Adresse = 04B0_0000h) mit dem Wert 83H (Rahmengröße = 3 und gesetztem seriellen Zugriffsbit).
- Lade ID Register (Adresse- 04B0_0001h) mit dem Wert 03H.
- Lade Daten/Steuerungsbyte: (Adresse- 04B0_0002H) mit dem Wert 08H, welches der KS0119 anzeigt, daß das näch ste Byte der Index ist).
- Lade Indexregister (Adresse = 04B0_0003H) mit dem Wert 6AH.

Die serielle Schnittstelle wird eine Übereinstimmung mit dem Inhalt des Rahmengrößenregisters erfassen und das Senden des Rahmens starten, ebenso wird die Schreibemarkierung in dem Statusregister auf den Besetzt-Zustand gesetzt werden. Die Software sollte die Markierungen in dem Statusregister über prüfen, bevor der nächste Rahmen geladen wird. Wenn die Mar kierungen in dem Bereit-Zustand sind, dann kann die Software die Werte für den nächsten Rahmen laden.

9.7 KS0122 Registerbeschreibung

Das KS0122 hat eine Basisadresse CODEC-REQ2 gleich 04C0 2000 und erstreckt sich bis 04C0 2FFF.

9.7.1 KS0122 Registeradressenabbild

9.7.2 Rahmengrößenregister

Dieses Register steuert die Rahmengröße, die an den CODEC Chip zu senden ist, wie in Fig. 62 definiert wird. Die mini male Rahmenlänge ist 3 Bytes.

9.7.3 Chip-ID-Register

Dieses Register sollte den CODEC Chip-ID-Wert enthalten und sollte 04H für KS0122 Schreiben und 84H für KS0122 Lesen ent halten.

9.7.4 Steuerung/DATENregister

Dieses Register informiert die CODEC Chips KS0122, daß das folgende gesendete BYTE ein Register INDEX- oder ein DATEN- byte sein wird. Für KS0122 = 00H bedeutet dies, daß INDEX das folgende Byte ist, und 01H bedeutet, daß DATEN das folgende Byte ist.

9.7.5 INDEX/DATEN0 Register

Dieses Register wird den INDEX-Wert für das CODEC Chip- Konfigurationsregister oder das DATEN0-Byte abhängig von dem Wert, der in dem vorangegangenen Byte gesendet wird, enthal ten. Bitte beziehen sie sich auf das Kommunikationsprotokoll in dem Programmierungsreferenzabschnitt.

9.7.6 DATEN1 Register

Dieses Register enthält die Daten, die in das CODEC Register zu schreiben sind, Index + 1.

9.7.7 DATEN2 Register

9.7.8 DATEN3 Register

9.7. 9 KS0122 Logik-Steuerungsregister

Die Bitzuordnungen für das KS0122 Steuerungsregister sind wie folgt:
Bits <1 : 0<
00 4 : 2 : 2 Format
01 4 : 1 : 1 Format
10 CCIR656 Format

9.7.10 Statusregister

Bit <0<: Feldstatus
0: gerades Feld
1: ungerades Feld
Bit <1<: VS Status
0: VS von 1 bis 0
1: VS von 0 bis 1

9.7.11 Serielles Schnittstellenregister für Lese-DATEN

Dieses Register wird die gültigen Daten von dem seriellen An schluß enthalten, nachdem die Lesemarkierung den Übergang von Besetzt- auf Bereit-Zustand hergestellt hat.

9.7.12 Serielle Protokoll-3-LEITUNGS-Schnittstelle an KS0122

Beim Setzen der Konfigurationsregister in dem KS0122 Chip ist das Protokoll wie folgt:

- Ein Minimum an zwei Rahmen müssen zu den peripheren Chips gesendet zu werden;
- der erste Rahmen soll den Index des Konfigurationsregi sters festsetzen;
- der zweite Rahmen ist zum Lesen und Schreiben der Daten (Inhalt des Registers).

Die Software sollte das Rahmengrößenregister auf die geeigne te Länge festsetzen und das serielle Zugriffbit = 1 setzen. Dann sollte die Software alle Bytes laden, die für den Rahmen erforderlich sind, bevor das Rahmengrößenregister verändert wird, wobei die CODEC Schnittstellenlogik warten wird, bis all die Bytes geladen sind, bevor eine Seriellumsetzung des Rahmens begonnen wird.

Das erste, das gesendet wird, soll den Index setzen. Die Rah mengröße = 3 Bytes. Es wird Bezug genommen auf Fig. 63.

Der zweite Rahmen soll das Register setzen. Die Rahmengröße = 3.

Nach jedem Datenbyte wird der Chip den Index um eins automa tisch erhöhen, welches ermöglicht, die aufeinanderfolgenden Register durch Senden von Mehrfachbytes an Daten zu setzen, wobei die CODEC Schnittstellenlogik bis zu vier Datenbytes unterstützt.

Wenn eine serielle Lese- oder Schreibfunktion durchgeführt wird, so sollte die SOFTWARE die Lese- und Schreibemarkierung des Statusregisters für gültige DATEN bei der Lesefunktion oder die Schreibemarkierung = bereit vor Senden des nächsten Rahmens überprüfen.

Das folgende Beispiel zeigt Schritt um Schritt das Setzen des KS0122 Konfigurationsregisters.

Um den Wert für das Chroma-Schlüssel-Byte 0 und -Byte 1 fest zu setzen, ist der Index für dieses Register 6 AH für Byte 0 und 6 BH für Byte 1, mit Bezug auf die KS0122 Datenblätter.

Da die zwei Register einen aufeinanderfolgenden Index haben, können diese zwei Bytes in einem einzigen Rahmen geladen wer den. Als erstes muß der Index festgesetzt werden, wie folgt:

- Lade Rahmengrößenregister (Adresse - 04B0_0000h) mit dem Wert 83H (Rahmengröße = 3 und serielles Zugriffsbit gesetzt).
- Lade ID Register (Adresse - 04B0_0001h) mit dem Wert 03H.
- Lade Daten/Steuerungsbyte: (Adresse - 04B0_0002H) mit dem Wert 08H, welcher dem KS0122 anzeigt, daß das näch ste Byte der Index ist).
- Lade Indexregister (Adresse = 04B0_0003H) mit dem Wert 6AH.

Die Serienschnittstelle wird eine Übereinstimmung mit dem In halt des Rahmengrößenregisters erfassen und das Senden des Rahmens starten, ebenso wird die Schreibemarkierung in dem Statusregister auf den Besetzt-Zustand gesetzt. Die Software sollte die Markierungen in dem Statusregister vor dem Laden des nächsten Rahmens überprüfen. Wenn die Markierungen in dem Bereit-Zustand sind, dann kann die Software die Werte für den nächsten Rahmen laden.

Kapitel 10 Bitstrom-Prozessor

10.1 Dieses Kapitel beschreibt die funktionellen Erforder nisse für den Aufbau des Bitstrom-Prozessors (BP), welcher einer der wichtigsten MSP Bearbeitungs-Prozessoren für die Video-Datenkomprimierungs- und Entkomprimierungsanwendungen ist.

10.2 Abkürzungen

A/V Audio(Ton) und Video
BP Bistrom-Prozessor (MSP Block)
CCU Cache-Steuerungseinheit (MSP Block)
CIF Gemeinsames Zwischenformat, welches Luminanzab tastauflösung von 352×288 bei 29,97 Hz hat
DCT Diskrete Cosinus-Transformation
DMA Direkter Speicherzugriff
DSM Digitale Speichermedien
FBUS Schneller Bus (Interner MSP Datenbus)
GOB Gruppe von Blöcken
GSTN Allgemein geschaltetes Telefonnetzwerk (ebenso als PSTN bekannt)
HDD Festplattenspeicher
I/F Schnittstelle
IOBUS Eingangs-Ausgangs-Bus (Interner Peripherie-MSP- Bus)
ISDN Dienstintegrierendes digitales Kommunikations netzwerk
ITU-T-601 Standard für die digitale Codierung von Farbfern sehsignalen, welche eine Luminanzabtastauflösung von 720×480 bei 29,97 Hz und 720×576 bei 25 Hz jeweils (früher wurde es CCIR 601 genannt) hat, jedoch kann die Anzeigeauflösung entweder 720×480 oder 704×480 sein
LSB geringstwertiges Bit
LUT Nachschlag-Tabelle
MPEG Bewegtbild-Expertengruppe
MSB höchstwertiges Bit
MSP Samsung Multimedia Signalprozessor
QCIF Viertel-CIF, welches eine Luminanzabtastauflösung von 176×144 bei 29,97 Hz hat
RLC Lauflänge und Niveau-Code
SDRAM Synchroner dynamischer Direktzugriffspeicher
SIF Quelleneingangsformat für MPEG-1 Video Standard, welcher eine Luminanzabtastauflösung von 352×240 bei 29,97 Hz für NTSC und 352×288 bei 25 Hz für PAL hat
TBD zu definieren
VLC variabler Längencode
VP Vektorprozessor (MSP Block)

10.3 Schlüsselmerkmale

- Unterstützt Syntax-Parsing und -Bildung für die Sli ce(oder GOB)-Schicht und unterhalb der MPEG-1, MPEG-2, H.261 und H.263 Codierungs- und Decodierungsanwendungen;
- Durchführen der RLC Verarbeitung in Real- bzw. Echtzeit;
- Durchführen der Huffman-Code-Verarbeitung in der Real zeit für alle Huffman-Tabellen, die in dem MPEG-1 MPEG-2, H.261 und H.263 Video Standard aufgelistet sind;
- Unterstützen von zwei Vorwärts/Inversen Zickzack-Scan- Umwandlungsregeln;
- IOBUS Schnittstellen mit maximaler Übertragungsrate von 731,4 Mbits/s (32-Bit @ 40 MHz);
- Maximale Betriebstaktfrequenz ist 40 MHz;
- beinhaltet 9,2 Kbit ROM für Huffman CODEC Tabellen;
- beinhaltet 320 Byte internen SRAM;
- unterstützt präemptive und kooperative Kontextschal tungsmoden;
- Target-Torzählung für Steuerungsweg ist 6 Kgates plus RAM und ROM.

10.4 Überblick

Der Bistrom-Prozessor (BP) ist einer von den vier internen MSP Peripheriegeräten. Er ist ein spezialisierter Hardware- Logikblock, um verschiedene Bitströme von Video-Kompressions- und Dekompressionsstandards zu unterstützen. Die Einheit ist besonders für Verarbeitung auf Bitebene aufgebaut, da VP und ARM7 innerhalb des MSP keine wirksame Architektur für solche Bitmanipulationen haben. Der BP sendet und empfängt Daten über einen 32 Bit-Bus, der IOBUS genannt wird, welcher eine maximale Übertragungsrate von 731,4 Mbits/s hat. Der BP ar beitet als eine unabhängige Verarbeitungseinheit und steht unter Software-Steuerung durch entweder die ARM7 oder den VP.

Insbesondere codiert und decodiert der BP alle Informationen, die in einer Slice- oder einer GOB-Schicht und darunter ent halten sind und empfängt und sendet die Daten von/zu der CCU. Der BP führt ebenso vorwärts und invers Zickzack-Umwandlungen durch und codiert und decodiert den Differential dc(Gleichstrom)-Koeffizienten. Des weiteren gewinnt der BP einen Bewegungsvektor wieder, der den differentiellen Bewe gungsvektor beim Decodieren benutzt, und führt die umgekehrte Funktion beim Codieren mit Ausnahme der folgenden zwei spezi ellen Moden durch, des Doppel-Primmodus beim MPEG-2-Codieren und dem vorprädiktiven Modus bei der H.263 Codierung und De codierung. Vom BP wird angenommen, daß er im Simplex-Modus funktioniert, d. h., sobald der BP begonnen hat, einen Slice oder eine GOB zu bearbeiten, wird der BP nicht unterbrochen werden, bis der aktuelle Slice oder GOB abgeschlossen ist. Dies impliziert, daß der komplette Duplex-Modus durch ver schachteltes Codieren und Decodieren der Slices oder GOBs vollendet werden kann. Wenn die ARM7 von dem BP wünscht, dringend zu einer anderen Aufgabe umzuschalten, so wird der BP den präemptiven Kontext-Schaltungsmodus unterstützen, wel cher den BP-Ablauf beenden kann, bevor die aktuelle Scheibe oder GOB vollendet sind.

Fig. 3 zeigt ein Blockdiagramm des BP. Wie aus Fig. 3 gesehen werden kann, beinhaltet der BP fünf Blöcke, die IOBUS Schnittstelleneinheit, die VLC FIFO Einheit, den VLC LUT ROM, die Steuerungszustandsmaschine und die BP Kern-Einheit. Die hineinkommenden und ausgehenden Daten werden alle durch die IOBUS Schnittstelleneinheit gehandhabt, welche einen 16×32 Bit RAM beinhaltet. Er unterstützt alle Datenbewegungen und Unterbrechungsanfragen. Die VLC FIFO Einheit soll das nächste Datenwort für die Datendecodierungsfunktion vorbereiten und das Ausgangsdatenpaket für die Datencodierungsfunktion durch führen. Der VLC-Tabellen-ROM hat die Größe von 768×12 Bit, so daß alle notwendigen Informationen für alle Huffman- Codeverarbeitungen gespeichert werden können. Die Steuerungs zustandsmaschine steuert alle Codierungs- und Decodierungsak tivitäten in diesem Aufbau. Die BP Kern-Einheit ist ein klei ner Prozessor, welcher Addierer, Vergleicher, Bitstellenver schieber, Registerdateien und einen 128×16 Bit RAM beinhal tet. Die Bitmanipulation ist aufgrund dieses Kernes verfüg bar.

10.5 Signaldefinitionen

Die Signale, die für die externe BP Schnittstelle erforder lich sind, sind in Tabelle 23 aufgelistet. Das Signal, wel ches mit den Buchstaben "_1" endet, bedeutet aktiv niedrig. Anzumerken ist, daß in der "Richtungs"-Spalte der Tabelle 1 "B", "I" und "O" das zweigerichtete Signal, das Eingangs signal bzw. das Ausgangssignal implizieren.

BP Signaldefinitionen

10.6 Datenfluß für Codierung/Decodierung

Dieser Abschnitt beinhaltet ein Datenflußbeispiel für typi sche Video-Codierungs- und Decodierungsanwendungen. Es ist anzumerken, daß dieses Dokument nicht den Audiodatenfluß im Detail beschreibt.

10.6.1 Codierungsfall Schritt E1: Ursprungs A/V Daten Ein

Es ist üblich, anzunehmen, daß die eingehenden Audio(Ton)- und Videosignale abgetastet und durch die externen CODECs di gitalisiert werden und dann in den Kunden ASIC gespeist wer den. In der Multimedia PC Umgebung beinhalten einige VGA Steuerungsleiterplatten ebenso Bildabtasteinrichtungen und Tonerfassungseinrichtungen. Deshalb wird angenommen, daß die Ursprungs A/V Daten von entweder dem Kunden ASIC oder der PCI Busschnittstelle gespeist werden. Sowohl die Kunden ASIC als auch die PCI Busschnittstelle beinhalten einen Puffer von kleiner Größe von 32 Bytes. Die Daten in diesem Puffer werden an den externen SDRAM über den FBUS durch Benutzen der DMA Logik übertragen. Anzumerken ist, daß diese Art von Datenbe wegung durch die ARM7 nach dem Leistungs-Ein-Zurücksetzen in itiiert werden soll.

Schritt E2: Vorfilterung durch den VP

Als erstes liest der VP die Ursprungsbilddaten, die in dem SDRAM gespeichert sind, in den VP Datencache aus (normaler weise der Zwischenspeicherbereich). Dann führt der VP tempo räres Filtern und räumliches Skalieren für diese Pixel durch. Durch Benutzen der Vorfilterung wird die Bildauflösung norma lerweise von der ITU-T-601 Größe in die CIF oder QCIF Größe umgewandelt. Der VP ist ebenso verantwortlich für das Schrei ben des vorgefilterten Ergebnisses an den externen SDRAM.

Schritt E3: Datenkompression durch den VP

Der VP liest die vorgefilterten Daten von dem SDRAM in den VP Datencache wiederum aus, um die Kompression entsprechend der Regel durchzuführen, die durch den korrespondierenden Stan dard vorgeschlagen wird. Normalerweise führt der VP den Vor wärts DCT, adaptive Vorwärts-Quantisierung, Bewegungsbewer tung, die Makroblocktypentscheidung usw. durch. Bei Abschluß dieser Funktionen sollte der VP das Ergebnis einschließlich einer geeigneten Kopfinformation wieder in den VP Datencache schreiben. Eigentlich kann dieser VP Datencache-Bereich als ein BP Eingangspuffer benutzt werden. Um den Pufferstatus zu überprüfen, wird ein Markierungssignal benutzt.

Schritt E4: BP Initialisierung durch die ARM7

Bevor der BP eigentlich seine Funktion startet, sollte die ARM7 die internen Register des BP initialisieren. Anzumerken ist, daß diese Initialisierung nicht während der 128 Zyklen durchgeführt werden sollte, nachdem das Leistungs-Ein- Rücksetzungssignal geltend gemacht wird. Insbesondere muß die ARM7 die Eingangs- und Ausgangspufferadressen und die BP Be fehlsregister initialisieren und die Zahl der Makroblocks, die innerhalb dieses Slices oder GOB zu codieren sind, be stimmen. Nach der Initialisierung dieser Register sollte die ARM7 die BP Einschaltmarkierung setzen, um die BP Verarbei tung zu aktivieren.

Schritt ES: Bitstromverarbeitung durch den BP

Wenn die eine oder andere Bank des Eingangsdoppelpuffers voll ist, so startet der BP das Lesen der Daten durch den IOBUS. Der BP kann die Daten nur lesen, wenn der Puffer voll ist. Dann wandelt der BP die 8×8 Blockdaten im Zickzackformat um und das Ergebnis wird direkt RLC- und Huffman-codiert. Das Huffman-codierte Ergebnis kann entweder an den ARM7 Daten cache oder den SDRAM gesendet werden. Der BP muß an den Aus gangspuffer nur schreiben, wenn der Puffer leer ist, um den Puffer vom Überlauf abzuhalten. Wenn das Ende der Verarbei tung erreicht ist (d. h. die Zahl der verarbeiteten Makro blocks ist gleich der Zahl der Makroblocks, die durch die ARM7 bestimmt werden), dann hat der BP die ARM7 mit der Byte- und Bit-Position der letzten Daten zu unterbrechen und been det die augenblickliche Slice- oder GOB-Verarbeitung.

Schritt E6: Bitstrombildung und A/V-Multiplexierung durch die ARM7

Die ARM7 bildet den endgültigen Bitstrom durch Kombinieren der Huffman-codierten Daten und der Syntaxparameter und wie derholt den Prozeß. Die ARM7 ist ebenso für das Handhaben der oberen Schichten des Slices oder des GOB verantwortlich und multiplexiert die Ton- und Video-Bitströme. Das Ergebnis wird in den SDRAM durch die ARM7 geschrieben.

Schritt E7: Netzwerkschnittstelle durch den VP (Option für Video-Konferenz)

Für Video-Fernsprech-oder Video-Konferenzanwendungen kann das Ergebnis von bis zu dem Schritt E6 weiterhin durch den VP verarbeitet werden, um eine Netzwerkschnittstellenfunktion durchzuführen, wie das V.34 Modem für H.324 GSTN Video Phone oder die 1.400 Serienschnittstelle für H.320 ISDN Videokonfe renzanschluß.

Schritt E8: Ausgabe des endgültigen Bitstroms

Der endgültige Bitstrom, der in dem SDRAM gespeichert wird, wird entweder an den Kunden ASIC oder die PCI Busschnittstel le übertragen. Normalerweise wird der Kunden ASIC für die Netzwerkschnittstelle benutzt werden und die PCI Busschnitt stelle wird für die Datenspeicherung in einer Aufnahmevor richtung (z. B. HDD) benutzt werden. Diese Datenbewegung be nutzt die DMA Datenübertragung, welche durch die ARM7 initi iert werden muß.

10.6.2 Decodierungsfall Schritt D1: Bitstromabruf

In der Multimedia PC Umgebung wird der komprimierte Bitstrom von dem CD_ROM Treiber, der HDD und der Netzwerkschnittstelle zugeführt. Deshalb wird angenommen, daß die Bitstromquelle entweder der Kunden ASIC oder die PCI Busschnittstelle sein könnte. Die Daten, die in dem 32-Byte Puffer des Kunden ASIC oder der PCI Busschnittstelle gespeichert werden, werden an den SDRAM durch Benutzen des DMA übertragen.

Schritt D2: Netzwerkschnittstelle durch den VP (Option für Video-Konferenz)

Bei der Video-Konferenz werden die Daten als erstes durch den VP verarbeitet, um die V.34- oder 1.400 Seriennetzwerk- Schnittstellenroutinen durchzuführen. Der VP wird das Ergeb nis in den SDRAM schreiben.

Schritt D3: A/V Demultiplexierung und Kopf-Parsing durch die ARM7

Die ARM7 bewegt die Daten in den SDRAM zu dem ARM7 Datencache und führt Demultiplexierung des A/V Bitstromes durch. Für den Video-Bitstrom ist die ARM7 ebenso für das Suchen aller Startcodes und Parsing-Köpfe verantwortlich, bis ein Slice oder eine GOB erfaßt wird. Die decodierten Bitstrom- Syntaxparameter können in dem speziellen Bereich des SDRAM durch die ARM7 gespeichert werden. Die demultiplexierten Ton- und Video-Bitströme werden an jeden der Vorhaltepuffer in dem SDRAM übertragen. Jede Anwendung kann verschiedene Größen für den Vorhaltepuffer haben. Z.B. empfiehlt der MPEG-1 370 Kbits und der MPEG-2 MP@ML macht 1,835 Mbits für die Video- Vorhaltepuffergröße.

Schritt D4: BP Initialisierung durch die ARM7

Der Ablauf für diesen Schritt ist derselbe wie in Schritt E4 in dem vorangegangenen Unterabschnitt mit Ausnahme der Tatsa che, daß die Initialisierung des Registers für die Zahl der Makroblocks, die zu codieren sind, nicht erforderlich ist. Wiederum sollte die Initialisierung nicht während der 128 Zy klen durchgeführt werden, nachdem das Leistungs-ein-Rück setzungssignal aktiviert wird.

Schritt D5: Bitstromverarbeitung durch den BP

Nach der Initialisierung des BP für den besonderen Slice oder GOB wird der Rest der Daten, die zu dekomprimieren sind, an den Eingangsdoppelpuffer gesendet. Der BP ist für das Lesen der Daten durch den IOBUS verantwortlich, der den Status der Voll-Markierung überprüft. Der BP muß die Syntaxparameter parsieren, wenn die Eingangsdaten das Kopfwort enthalten. Wenn der BP erkennt, daß die nächsten Bits ein Huffman-Code sind, so führt er eine Huffman-Decodierung innerhalb von höchstens vier Zyklen für jeden Huffman-Code durch. Wenn die Huffman-Codes für die DCT AC Koeffizienten sind, so wird das Huffman-decodierte Ergebnis RLC decodiert, um 64 Pixel- Komponenten zu erzeugen. Die rekonstruierten Pixel werden in vers zickzack-umgewandelt und schließlich an den Ausgangsdop pelspeicher gesendet, um den VP die Vorwärtsquantisierung durchführen zu lassen. Der BP sollte die Verarbeitung weiter führen, bis ein Nicht-Slice- oder Nicht-GOB-Startcode erfaßt wird. Wenn sie erfaßt werden, so muß der BP die ARM7 mit der Byte- und Bitpositionsinformation für die letzten Daten, die benutzt werden, unterbrechen und die Verarbeitung beenden. Die ARM7 sollte dann nach dem nächsten Slice- oder GOB-Start code suchen und den Ablauf wiederholen.

Schritt D6: Datendekomprimierung des VP

Durch Benutzen des Ergebnisses von Schritt D5 sollte der VP eine inverse Quantisierung, inverse DCT und Bildrekonstrukti on durch Benutzen von Bewegungsvektoren durchführen. Nach Vollendung der Decodierung wird der VP das Ergebnis in den SDRAM speichern.

Schritt D7: Nachverarbeitung durch den VP

Bevor die Video- und Audio(Ton)daten schließlich an die Digi tal-Analogumwandler gesendet werden, werden die Pixel durch den VP nachverarbeitet, um die gewünschte Ausgangsauflösung und die Bildqualität zu erhalten. Das Ergebnis wird dann wie der in dem SDRAM gespeichert.

Schritt D8: Ausgabe der Ursprungs-A/V-Daten

Schließlich werden die rekonstruierten Ton- und Videodaten in dem SDRAM unter Verwendung des DMA ausgegeben werden. Wieder um sollte diese Art von Datenbewegung durch den ARM7 initi iert werden. Da die moderne Videoüberlagerungstechnik dem PCI Bus ermöglicht, die Video-Quellendaten zu senden, werden die endgültigen Ursprungsdaten entweder an den Kunden ASIC oder die PCI Busschnittstelle gesendet.

10.7 Programmierungsmodell 10.7.1 BP Basis-Vorrichtungsadresse

Der BP hat die folgende 32-Bit Basis-Vorrichtungsadresse:

<MSP_BASE<<BP_BASE<<Address_Offset<

worin
<MSP_BASE< 5 Bit sind, welche durch die MSP PCI Basis-Vor richtungsadresse spezifiziert werden,
<BP_BASE< 7 Bit sind, welche gleich mit 7'b1111100 sind,
und
<Address_Offset< 20 Bit sind, welche für die BP internen Re gister zugeordnet werden.

Deshalb ist der Adressenbereich, der für den BP zugeordnet wird, in der gesamten MSP I/O Vorrichtungsadressenliste von 27'h 7C0_0000 bis 27'h 7CF_FFFF.

10.7.2 Beschreibung der internen Register

Der interne Registersatz wird in der Tabelle 24 beschrieben. Alle Register, die in Tabelle 2 wiedergegeben werden, können durch die ARM7 oder den VP gelesen und geschrieben werden.

Interne BP Register

- BP_MODE[31 : 0] (Nur lesen, kein Standardwert) - dieses Register soll den Video-Standardtyp und die verschiede nen Bildniveau-Informationen bezeichnen. Die Details können in dem Unterabschnitt 10.8.1 gefunden werden.
- BP_CONTROL[31 : 0] (lesen/schreiben, Standardwert ist "32'h0000_0000) - dieses Register beinhaltet verschiede ne Steuerungsparameter für die BP Operationen. Die ARM7 oder der VP wird jede Markierung in diesem Register set zen und einige Markierungen werden durch die BP zurück gesetzt. Die Bitbeschreibung kann in dem Unterabschnitt 10.8.2 gefunden werden.
- IBUF0_START[31 : 0] (lesen/schreiben, keine Standardwerte) - dieses Register wird durch die ARM7 initialisiert, um die Startadresse für den Eingangspuffer 0 des BP Ein gangsdoppelpuffers zu melden. Anzumerken ist, daß der Initialisierungswert für IBUF0_START immer kleiner als IBUF0_ENDE sein sollte und IBUF0_START[3 : 0] sollte gleich 4'b0000 sein. Der Gebrauch wird in dem Abschnitt 10.11 beschrieben.
- IBUF0_END[31 : 0] (nur lesen, keine Standardwerte) - dieses Register soll die Endadressen für den Eingangspuffer 0 des BP Eingangsdoppelpuffers bezeichnen. Der Gebrauch wird in dem Abschnitt 10.11 beschrieben.
- IBUF1_START[31 : 0] (lesen/schreiben, keine Standardwerte) - dieses Register wird durch die ARM7 initialisiert, um die Startadresse für den Eingangspuffer 1 des BP Ein gangsdoppelpuffers zu melden. Anzumerken ist, daß der Initialisierungswert für IBUF1_START immer kleiner als IBUF1_END sein sollte, und IBUF1_START[3 : 0] sollte gleich 4'b0000 sein. Der Gebrauch wird in dem Abschnitt 10.11 beschrieben.
- IBUF1_END[31 : 0] (nur lesen, keine Standardwerte) - dieses Register soll die Endadressen für den Eingangspuffer 1 des BP Eingangsdoppelpuffers bezeichnen. Der Gebrauch wird in dem Abschnitt 10.11 beschrieben.
- OBUF0_START[31 : 0] (lesen/schreiben, keine Standardwerte) - dieses Register wird durch die ARM7 initialisiert, um die Startadresse für den Ausgangspuffer 0 des BP Aus gangsdoppelpuffers zu melden. Anzumerken ist, daß der Initialisierungswert für OBUF0_START immer kleiner als OBUF0_ENDE sein sollte, und OBUF0_START[3 : 0] sollte gleich 4'b0000 sein. Der Gebrauch wird in dem Abschnitt 10.11 beschrieben.
- OBUF0_END[31 : 0] (nur lesen, keine Standardwerte) - dieses Register soll die Endadressen für den Ausgangspuffer 0 des BP Ausgangsdoppelpuffers bezeichnen. Der Gebrauch wird in dem Abschnitt 10.11 beschrieben.
- OBUF1_START[31 : 0] (lesen/schreiben, keine Standardwerte) - dieses Register wird durch die ARM7 initialisiert, um die Startadresse für den Ausgangspuffer 1 des BP Aus gangsdoppelpuffers zu melden. Anzumerken ist, daß der Initialisierungswert für OBUF1_START immer kleiner als OBUF1_ENDE sein sollte und OBUF1_START[3 : 0] sollte gleich 4'b0000 sein. Der Gebrauch wird in dem Abschnitt 10.11 beschrieben.
- OBUF1_END[31 : 0] (nur lesen, keine Standardwerte) - dieses Register soll die Endadressen für den Ausgangspuffer 1 des BP Ausgangsdoppelpuffers bezeichnen. Der Gebrauch wird in dem Abschnitt 10.11 beschrieben.
- SAVE_ADR[31 : 0] (nur lesen, kein Standardwert) - dieses Register soll die Startadresse des SDRAM bezeichnen, um den BP internen Kontext zu sichern, wenn der präemptive Kontextschaltungsmodus angefragt wird. Einige diesbezüg liche Beschreibungen können in dem Unterabschnitt 10.12.1 gefunden werden.
- VALID_BYTE_ADR[31 : 0] (lesen/schreiben, keine Standard werte) - dieses Register soll die letzte gültige Daten byteposition des Eingangsdoppelpuffers beim Decodieren oder die des Ausgangsdoppelpuffers beim Codieren anzei gen. Der Zweck dieses Registers ist für den Job- Quittungsbetrieb zwischen der ARM7 und dem BP. Im allge meinen ist eine zusätzliche Information für die gültige Bitposition der gültigen Bytedaten ebenso erforderlich, welche in dem BP_CONTROL[31 : 0] Register beinhaltet ist. Details können in dem Abschnitt 10.13 gefunden werden.
- BP_STATUS[31:0] (lesen/schreiben, Standardwert ist "32'h0000_0000") - dieses Register soll die verschiede nen internen Statusse des BP bezeichnen. Jede Bitpositi on in den unteren zwei Bytes (d. h. BP_STATUS[l5 : 0]) ist ein Unterbrechungszustand, welcher den ARM7_IRQ auf "1" setzen kann. Auf dieses Register kann auf zwei Wegen zu gegriffen werden. Die ARM7 oder der VP können dieses volle 32 Bit-Register durch Benutzen der Adresse 27'h7C0_0050 lesen oder schreiben. Im allgemeinen jedoch wird die ARM7 und der VP es vorziehen, den Inhalt des BP_STATUS Registers Bit um Bit zu schreiben (oder zu rückzusetzen). Der BP unterstützt ebenso dieses Merkmal durch Zuordnen der Adresse, die von 27'h7C0_0030 bis 27'h7C0_004F für jedes Bit von BP_STATUS reicht. Die de taillierte Beschreibung kann in dem Unterabschnitt 10.8.3 gefunden werden.
- BP_INT_MASK[15 : 0] (nur lesen, Standardwert ist "16hFFFF") - jedes Bit in diesem Register korrespondiert mit einem Unterbrechungszustand, der durch BP_STATUS[15 : 0] gegeben wird und wird logischerweise mit dem Zustand enden, bevor dieser in BP_STATUS [15 : 0] ge laden wird. Wenn ein Maskierungsbit auf "0" gesetzt wird, so wird der korrespondierende Unterbrechungszu stand bedingungslos auf "0" (d. h. gesperrt) gesetzt. De tails zu der Unterbrechung können in dem Abschnitt 10.9 gefunden werden.
- V_MB_SIZE[7 : 0] (nur lesen, kein Standardwert) - dieses Register bezeichnet die vertikale Größe des Bildes, das zu codieren oder decodieren ist. Es ist anzumerken, daß der Wert in der Anzahl der Makroblocks beschrieben wer den muß. Z.B., wenn die vertikale Größe 288 Bildelemente ist, so ist V_MB_SIZE[7 : 0] = 288/16 = 18. Die ARM7 ist für das Setzen dieses Wertes vor jedem Start der BP- Codierungs- und Decodierungsfunktion verantwortlich.
- H_MB_SIZE[7 : 0] (nur lesen, kein Standardwert) - dieses Register bezeichnet die horizontale Größe des Bildes, das zu codieren oder decodieren ist. Es ist anzumerken, daß der Wert in der Zahl der Makroblocks geschrieben werden muß. Z.B., wenn die horizontale Größe 352 Bild elemente ist, so ist H_MB_SIZE[7 : 0] = 352/16 = 22. ARM7 ist für das Setzen dieses Wertes vor jedem Start der BP Codierungs- und Decodierungsfunktion verantwort lich.
- ARM7_IRQ[0] (nur schreiben, Standardwert ist "0") - dieses Register ist eine 1-Bit Markierung, um die Unterbre chung an die ARM7 anzufragen und wird direkt mit dem Ausgangsanschluß ARM7_IRQ verbunden. Diese Markierung wird gesetzt werden, wenn irgendein Bit des BP_STATE[15 : 0] auf "1" gesetzt wird. Die ARM7 ist für das Zurücksetzen dieser Markierung verantwortlich.

10.8 BP I/O-Datenwortformat

Dieser Abschnitt deckt das Befehlsdaten- und Makroblockdaten wortformat für BP Eingang und Ausgang ab.

10.8.1 BP_MODE Registerformat

Das 32-Bit-BP MODE-Register bei der Adresse von 27'h7C0_0000 hat das folgende Format, das in Tabelle 25 vorgegeben wird. Anzumerken ist, daß BP_MODE[31] = PARAM_SET2[7] und BP_MODE[0] = SF[0].

BP_MODE-Registerformat

- standard_format (SF) - der zu benutzende Videostandard, welcher in Tabelle 26 definiert wird. Der SF sollte im mer durch die ARM7 spezifiziert werden, bevor der BP für alle Videocodierungs- und -decodierungsanwendungen akti viert wird.
Definition von SF

Definition von SF
- picture_typ (PT) - der Bildcodierungstyp, welcher in Ta belle 27 definiert wird. Anzumerken ist, daß der Wert 00 für PT spezielle Fälle für MPEG-1, MPEG-2 und H.263 An wendungen bedeutet. Insbesondere wird das D-Bild als ein Bildtyp für MPEG-2 zugeordnet, obwohl es nicht in dem MPEG-2 benutzt werden sollte. Dies ist so, da der MPEG-1 Bitstrom ein Untersatz von dem MPEG-2 Bitstrom ist.
Definition des PT

Definition des PT
- picture_structure (PS) - die Bildstrukturinformation, welche in Tabelle 28 definiert wird. Wiederum ist der Wert 00 für PS illegal und resultiert in einem Fehler.
Definition des PS

Definition des PS
- parameter_set0, 1 und 2 (PARAM_SET0, PARAM_SET1, PARAM_SET2) - diese drei Bytes sollen verschiedene Para meter bezeichnen, die für MPEG-1, MPEG-2 und H.263-An wendungen benötigt werden. Die Definitionen für jeden Parametersatz werden in den Tabellen 29 und 30 beschrie ben.
Definition von PARAM_SET0

Definition von PARAM_SET0
- intra_dc-precision (IDP) - 2-Bit intra dc Präzisionspa rameter, der in dem MPEG-2 definiert wird, welcher auf 00 in der MPEG-1 Anwendung gesetzt werden sollte.
- top_field first (TFF) - eine Markierung für MPEG-2, die bei Bewegungsvektorcodierung und -decodierung benutzt wird.
- frame_pred_frame_dct (FPFD) - eine Markierung für den MPEG-2, um anzuzeigen, daß Rahmen-DCT und Rahmenvoraus sage benutzt werden.
- concealment_motion_vectors (CMV) oder advan ced_prediction_mode (AP) - im MPEG-2, diese Markierung wird benutzt, um anzuzeigen, daß die Bewegungsvektoren in den intra-Makroblocks benutzt werden. In dem H.263 wird die Markierung auf 1 gesetzt, wenn der fortge schrittene Vorhersagemodus EIN ist, andererseits sollte sie auf 0 gesetzt werden.

Für andere Standards sollte diese Markierung auf 0 gesetzt werden.

- intra_vlc_format (IVF)-eine Markierung für MPEG-2, um den VLC-Tabellentyp für intra-Makroblocks zu bestimmen.
- alternate scan (AS)-eine Markierung für den MPEG-2, um die Reihenfolge der Koeffizienten, die zu codieren und decodieren sind, zu bestimmen.
- vertical_size_flag (VSF) oder conti nous_presence_multipoint (CPM) - bei MPEG-1 und MPEG-2, diese Markierung wird auf 1 gesetzt, wenn die vertikale Größe des Bilds 2800 Zeilen überschreitet, ansonsten sollte sie auf 0 gesetzt werden. Bei H.263 wird diese Markierung auf 1 gesetzt, wenn der stetige Anwesenheits- Multipunktmodus benutzt wird, andererseits sollte sie auf 0 gesetzt werden.
Definition von PARAM_SETI und PARAM_SET2

Definition von PARAM_SETI und PARAM_SET2

10.8.2 BP_CONTROL(Steuerungs)-Registerformat

Die Bitbeschreibung für das BP_CONTROL[31:]-Register (Adresse 27'h 7C0_0004) wird in Tabelle 31 gezeigt.

BP_CONTROL-Registerformat

161 TI=TAB<

- BP_enable (BP_EN) - wenn diese Markierung auf "1" durch die ARM7 oder den VP gesetzt wird, so startet der BP die Verarbeitung. Deshalb sollten alle anderen Registerkon figurationen getan sein, bevor diese Markierung gesetzt wird. Wenn der BP die Verarbeitung abschließt, wird die se Markierung durch den BP gelöscht.
- software_reset (SOFT_RESET) - wenn diese Markierung auf "1" durch die ARM7 oder den VP gesetzt wird, so stoppt der BP die momentane Verarbeitung, stellt alle internen Register zurück auf den Standardzustand und fällt in den Leerlaufzustand. Die ARM7 kann die BP Verarbeitung durch Setzen von BP_EN Markierung wieder starten. Das BP Hard ware-Rücksetzungssignal ist aktiv niedrig.
- pause (PAUSE) - wenn diese Markierung auf "1" durch die ARM7 oder den BP gesetzt wird, so friert der BP den lau fenden Verarbeitungsablauf ein. Die Benutzer können die Pausenfunktion durch Setzen der BP_EN Markierung wieder aufnehmen.
- detect_start_code (DETECT_START_CODE) - wenn diese Mar kierung auf "1" durch die ARM7 oder den VP gesetzt wird, so findet der BP den nächsten Startcode unter den Daten in dem IBUF0. Somit sollte der Benutzer die geeigneten Adressen für IBUF0_START und IBUF0_ENDE setzen. Es ist erforderlich, daß dieser Befehl nur sauber arbeiten wird, wenn der BP in einem Leerlaufzustand ist. Somit sollte die ARM7 den Software-Rücksetzungsbefehl zuerst an den BP senden, bevor dieser Befehl ausgesendet wird, wenn der BP nicht im Leerlauf ist.
- step (STEP) - wenn diese Markierung auf "1" durch die ARM7 oder den VP gesetzt ist, so schreitet der BP einen Zustand der momentan laufenden Verarbeitung voran. Dies ist ein sehr nützliches Merkmal zum Fehlerbeseitigen. Die ARM7 sollte den Pausenbefehl zuerst senden, um die Schrittfunktion zu ermöglichen.
- context_switching_reset (CTX_SWITCH) - wenn diese Mar kierung auf "1" durch die ARM7 gesetzt wird, so führt der BP entweder präemptive oder kooperative Kontext schaltung entsprechend dem Inhalt von CTX_Mode durch. Details können in dem Abschnitt 10.12 gefunden werden.
- context_switching_mode (CTX_MODE) - wenn diese Markie rung auf "1" durch die ARM7 oder den VP mit Setzen des CTX_SWITCH als "1" gesetzt wird, so führt der BP den präemptiven Kontext-Schaltungsmodus durch. Wenn er auf "0" mit dem Setzen des CTX_SWITCH auf "1" gesetzt wird, so führt der BP den kooperativen Kontext-Schaltungsmodus durch. Anzumerken ist, daß das CTX_MODE-Setzen ohne Set zen von CTX_SWITCH auf "1" nicht die BP Verarbeitung be einflußt. Details für die Kontextschaltung können in Ab schnitt 10.12 gefunden werden.
- context_reload_request (CTX_RELOAD) - wenn diese Markie rung auf "1" durch die ARM7 oder den VP gesetzt wird, so lädt der BP den vorangegangenen gesicherten Kontext in den SDRAM wieder. Der BP ist für das Lesen des Kontextes verantwortlich, welcher von der Adresse SICHERN_ADR[31 : 0] gespeichert ist. Details für das Kon textschalten können in dem Abschnitt 10.12 gefunden wer den.
- error_handle_mode (ERR_HANDLE_MODE) - diese Markierung wird benutzt, um das Fehleraufdeckungsverfahren des BP zu beschleunigen, wenn ein Fehler in dem gesendeten kom primierten Bitstrom auftritt. Wenn der eingehende Bitstrom ungültige Daten hat, so muß der BP die ARM7 un terbrechen und den Inhalt dieser Markierung überprüfen. Wenn diese Markierung auf "1" gesetzt wird, so findet der BP automatisch den nächsten Startcode. Wenn der Startcode für einen Slice (Scheibe) oder ein GOB ist, so nimmt der BP die Verarbeitung wieder auf. Wenn diese Markierung auf "0" gesetzt wird, so muß der BP in den Leerlaufzustand fallen, ohne den nächsten Startcode zu suchen. Details für diesen Job-Quittungsbetrieb zwischen dem BP und dem ARM7 werden in dem Abschnitt 10.13 be schrieben.
- number_of_macroblocks_to_be_encoded (NO_MBS[15 : 0]) - dieses Register beinhaltet die 16-Bit vorzeichenlose Ganzzahl, welche die Zahl der Makroblocks, die in diesem Slice oder der GOB zu codieren sind, anzeigt. Durch Be nutzen dieser Bitauflösung können bis zu 65535 Makro blocks in einem Slice (Scheibe) oder einer GOB codiert werden. Hier ist der Wert "0" nicht als eine Zahl der Makroblocks erlaubt.

10.8.3 BP_STATUS Registerformat

Die Bitbeschreibung des BP_STATUS[31 : 0]-Registers (Adresse 27'h 7C0_0050) wird in Tabelle 32 gezeigt.

BP_STATUS Registerformat

- input_buffer_0_done (IBUF0_DONE) - eine Markierung, um zu melden, daß die Daten in dem Eingangspuffer 0 alle durch den BP verbraucht sind. Diese Markierung wird durch den BP gesetzt und durch die ARM7 oder den VP ge löscht. Anzumerken ist, daß diese Markierung ein Unter brechungszustand ist.
- input_buffer_1_done (IBUF1_DONE) - eine Markierung, um zu melden, daß die Daten in dem Eingangspuffer 1 alle durch den BP verbraucht sind. Diese Markierung wird durch den BP gesetzt und durch die ARM7 oder den VP ge löscht. Anzumerken ist, daß diese Markierung ein Unter brechungszustand ist.
- output_buffer_0_full (OBUF0_FULL) - eine Markierung, um zu melden, daß der Ausgangspuffer 0 durch den BP aufge füllt wird. Diese Markierung wird durch den BP gesetzt und durch die ARM7 oder den VP gelöscht. Anzumerken ist, daß diese Markierung ein Unterbrechungszustand ist.
- output_buffer_1_full (OBUF1_FULL) - eine Markierung, um zu melden, daß der Ausgangspuffer 1 durch den BP aufge füllt ist. Diese Markierung wird durch den BP gesetzt und durch die ARM7 oder den VP gelöscht. Anzumerken ist, daß diese Markierung ein Unterbrechungszustand ist.
- BP_processing_done (BP_DONE) - eine Markierung, um zu melden, daß der BP die Codierung eines Slice (Scheibe) oder einer GOB vollendet hat oder einen Nicht-Scheibe- oder einen Nicht-GOB-Startcode im Falle der Decodierung hat. Diese Markierung wird durch den BP gesetzt und durch die ARM7 oder den VP gelöscht. Anzumerken ist, daß diese Markierung ein Unterbrechungszustand ist.
- context_switching_done (CTX_SW_DONE) - eine Markierung, um zu melden, daß der BP bereit ist, auf einen anderen Task im Kontextschaltungsmodus umzuschalten. Diese Mar kierung wird durch den BP gesetzt und durch die ARM7 oder den VP gelöscht. Anzumerken ist, daß diese Markie rung ein Unterbrechungszustand ist.
- context_reload_done (CTX_RELOAD_DONE) - eine Markierung, um zu melden, daß der BP die Wiederladefunktion für den Kontext, der von der Adresse SAVE_ADR[31 : 0] gesichert wird, vollendet hat. Diese Markierung wird durch den BP gesetzt und durch die ARM7 oder den VP gelöscht. Anzu merken ist, daß diese Markierung ein Unterbrechungszu stand ist.
- BP_error_flag (BP_ERR) - eine Markierung, um zu melden, daß ein Fehler in dem BP auftritt während der Verarbei tung der Daten. Diese Markierung wird gesetzt, wenn BP_ERR_CODE[7 : 0] (= BP_STATUS[31 : 24]) nicht gleich Null ist. Details können in dem Unterabschnitt 10.9.2 gefun den werden.
- input_buffer_0_full (IBUF0_FULL) - eine Markierung, um anzuzeigen, daß die Daten in dem Eingangspuffer 0 durch die ARM7 oder den VP aufgefüllt sind. Diese Markierung wird durch die ARM7 oder den VP gesetzt und durch den BP gelöscht.
- input_buffer_1_full (IBUF1_FULL) - eine Markierung, um anzuzeigen, daß die Daten in dem Eingangspuffer 1 durch die ARM7 oder den VP aufgefüllt sind. Diese Markierung wird durch die ARM7 oder den VP gesetzt und durch den BP gelöscht.
- output_buffer_0_done (OBUF0_DONE) - eine Markierung, um anzuzeigen, daß die Daten in dem Ausgangspuffer 0 alle durch die ARM7 oder den VP aufgebraucht sind. Diese Mar kierung wird durch den ARM7 oder den VP gesetzt und durch den BP gelöscht.
- output_buffer_1_done (OBUF1_DONE) - eine Markierung, um anzuzeigen, daß die Daten in dem Ausgangspuffer 1 alle durch die ARM7 oder den VP aufgebraucht sind. Diese Mar kierung wird durch die ARM7 oder den VP gesetzt und durch den BP gelöscht.
- valid_bit_position (VALID_BIT_POS[2 : 0]) - 3-Bit Informa tion, um die gültige Bitposition unter dem Datenbyte an zuzeigen, das bei VALID_BYTE_ADR[31 : 0] für die nächste Verarbeitung gespeichert ist. Bei der Video-Codierung muß der BP den Wert setzen und die ARM7 sollte den näch sten Ablauf von dieser Bitposition aus starten. In der Video-Decodierung muß die ARM7 diesen Wert setzen und der BP sollte den Ablauf von dieser Bitposition starten.
- BP_error_code (BP_ERR_CODE[7 : 0]) - 8-Bit Information, um zu melden, welche Art von Fehler in dem BP aufgetreten ist. Der Wert Null bedeutet, daß kein Fehler aufgetreten ist. Details können in dem Unterabschnitt 10.9.2 gefun den werden.

10.8.4 Eingangsdatenformat für die Decodierung und Ausgangs datenformat für die Codierung

In diesem Fall bestehen die Daten eigentlich aus dem kompri mierten Bitstrom. Die Daten können Startcodes, Kopfparameter und komprimierte Daten entsprechend dem korrespondierenden Standard beinhalten. Dieser Bitstrom ist Byte an Byte ge packt, jedoch muß er nicht in einigen Anwendungen Byte ausgerichtet sein. Anzumerken ist, daß der Bitstrom Daten für mehrere Slices (Scheiben) oder GOBs enthalten kann.

10.8.5 Eingangsdatenformat zum Codieren und Ausgangsdaten format zum Decodieren

In diesem Fall bestehen die Daten eigentlich aus Makroblock- Kopfinformation, Bewegungsdaten und Pixel-Koeffizientendaten. Das Format für jede Art von Daten wird im folgenden defi niert.

10.8.5.1 Makroblock-Kopfwort

Der Makroblockkopf sollte immer aus sechs Bytes bestehen und hat das folgende Datenformat, das in Tabelle 33 aufgezeigt wird.

Makroblock-Kopfwortformat

Hier werden die Parameter, die in der obigen Tabelle gegeben werden, wie folgt definiert:

- Vertikale Makroblockadresse (VMA) oder group_number (GRNO) - dieses Byte bedeutet die vertikale Makroblock position, welche einen Wert von 1 bis 255 haben kann. Anzumerken ist, daß die erste vertikale Position mit 1 und nicht 0 numeriert wird. Als einen Ausnahmefall be zeichnet bei der H.261 Codierung dieses Feld die group_number-Information, welche die Position der Gruppe der Blöcke mitteilt.
- Horizontale Makroblockadresse (HMA) oder macro block_position (MBPS) - dieses Feld bedeutet die hori zontale Makroblockposition, welche einen Wert von 1 bis 255 haben kann. Anzumerken ist, daß die erste horizonta le Position als 1 und nicht als 0 numeriert wird. Als ein Ausnahmefall bezeichnet bei der H.261 Codierung die ses Feld eine von 33 möglichen Positionen des Makro blocks unter der GOB.
- macroblock intra (I) - Wenn der momentane Makroblock in tracodiert ist, wird er auf 1 gesetzt. Andererseits wird er auf 0 gesetzt.
- macroblock_pattern (P) - Wenn der momentane Makroblock codierte Blocks beinhaltet, so wird er auf 1 gesetzt. Andernfalls wird er auf 0 gesetzt.
- macroblock_quant (Q) - Wenn der momentane Makroblock ei nen neuen Quantisierungsmaßstab-Parameter hat, so wird er auf 1 gesetzt. Andernfalls wird er auf 0 gesetzt.
- macroblock_motion_forward (MF) - Wenn der momentane Ma kroblock vorwärts vorhergesagt wird, so wird er auf 1 gesetzt. Andernfalls wird er auf 0 gesetzt.
- macroblock_motion_backward (MB) - Wenn der momentane Ma kroblock rückwärts vorhergesagt wird oder B-Blocks in dem H.263 beinhaltet, so wird er auf 1 gesetzt. Andern falls wird er auf 0 gesetzt.
- dct-Typ (DT), loop_filter (LF), oder advanced_prediction (M4) - Das Bit [5] des Bytes2 hat verschiedene Bedeutung in jeder Anwendung. Im MPEG-1 wird es nicht benutzt. Im MPEG-2 bezeichnet es den dct_Typ. Wenn der Makroblock Feld-DCT-codiert ist, so wird diese Markierung auf 1 ge setzt. Wenn er Rahmen-DCT-codiert ist, so wird er auf 0 gesetzt. Bei H.261 wird diese Markierung gesetzt, wenn das Schleifenfilter bei dem momentanen Makroblock be nutzt wird. Andererseits wird sie auf 0 gesetzt. Bei H.263 wird sie, wenn der momentane Makroblock den fort geschrittenen Vorhersagemodus benutzt, auf 1 gesetzt. Andernfalls wird sie auf 0 gesetzt.
- motion_typ (MT) - Dieses 2-Bit Feld zeigt den fra me_motion_type oder den field_motion_type an, der in dem MPEG-2 benutzt wird, welches die folgende Bedeutung wie in Tabelle 34 und 35 hat. Anzumerken ist, daß der Wert 00 reserviert ist.

Bedeutung des frame_motion_type

Bedeutung von field_motion_type

- quantizer_scale (Q_SCALE) - Eine Ganzzahl ohne Vorzei chen in dem Bereich von 1 bis 31 wird benutzt, um das Rekonstruktionsniveau der DCT Koeffizientenniveaus zu skalieren. Jeder Makroblockkopf sollte einen geeigneten Wert für diesen Parameter beinhalten, obwohl der Wert derselbe wie der des vorangegangenen Makroblockes (d. h. macroblock_quant ist Null) ist. Beim Codieren ist der Benutzer für das Schreiben des geeigneten Wertes in die ses Feld verantwortlich. Beim Decodieren schreibt der BP den Huffman-decodierten quantizer_scale-Wert in dieses Feld. Wenn der momentane Makroblock nicht den Huffman- Code für dieses Feld beinhaltet, so schreibt der BP den Maßstabswert des vorangegangenen Makroblocks.
- coded_block_pattern_0 (CBP_0) - Ein 6 Bit-Mustercode wird benutzt, um die codierten Blocks in dem aktuellen Makroblock zu bezeichnen, wobei gilt:
CBP_0[5] → Luminanz (Y) 0 Block
CBP_0[4] → Luminanz (Y) 1 Block
CBP_0[3] → Luminanz (Y) 2 Block
CBP_0[2] → Luminanz (Y) 3 Block
CBP_0[1] → Chrominanz blau (Cb) Block
CBP_0[0] → Chrominanz rot (Cr) Block
- coded_block_pattern_1 (CBP_1) - Zusätzliches coded_block_pattern für die B-Blocks der PB-Rahmen in der H.263 Anwendung, wobei gilt:
CBP_1[5] → Luminanz (Y) 0 Block
CBP_1[4] → Luminanz (Y) 1 Block
CBP_1[3] → Luminanz (Y) 2 Block
CBP_1[2] → Luminanz (Y) 3 Block
CBP_1[1] → Chrominanz blau (Cb) Block
CBP_1[0] → Chrominanz rot (Cr) Block
- logical_channal_indicator (LCI) - Eine 2-Bit Information für die GOB logische Kanalnummer wird nur in dem fort laufenden Anwesenheits-Multipunktmodus von H.263 be nutzt.
- frame_id (FID) - Eine 2-Bit Information für die GOB Rah men-ID für H.263.
- macroblock_address_increment (MBA_INC) - 2-Byte Informa tion für den Makroblock-Adressenerhöhungswert des aktu ellen Makroblocks. Diese Information wird immer von dem BP als zusätzliche Information geliefert, so daß die Be nutzer nicht sie in dem Eingangsformat festsetzen müs sen. Jeder Wert, der in dem Eingangsmakroblock-Kopfwort spezifiziert wird, wird durch den BP ignoriert werden.
- previous_dc_luminance (PRE_DC_Y) - 2 Byte-Information für den dc-Wert des Luminanzblockes des vorangegangenen Makroblocks. Wenn es übersprungene Makroblocks gibt, so wird der Zurücksetzungswert übertragen. Diese Informati on wird immer durch den BP als zusätzliche Information geliefert, so daß die Benutzer sie nicht bei dem Ein gangsformat festsetzen müssen. Jeder Wert, der in dem Eingangsmakroblock-Kopfwort spezifiziert wird, wird durch den BP ignoriert werden.
- previous_dc_chrominance_blue (PRE_DC_Cb) - 2 Byte- Information für den dc-Wert des blauen Chrominanzblockes des vorangegangenen Makroblockes. Wenn es übersprungene Makroblöcke gibt, so wird der Rücksetzungswert übertra gen. Diese Information wird immer durch den BP als zu sätzliche Information geliefert, so daß die Benutzer sie nicht in dem Eingangsformat festsetzen müssen. Jeder Wert, der in dem Eingangsmakroblock-Kopfwort spezifi ziert wird, wird durch den BP ignoriert werden.
- previous_dc_chrominance_red (PRE_DC_Cr) - 2 Byte- Information für den dc-Wert des roten Chrominanzblockes von dem vorangegangenen Makroblock. Wenn es übersprunge ne Makroblöcke gibt, so wird der Rücksetzungswert über tragen. Diese Information wird immer durch den BP als zusätzliche Information geliefert, so daß die Benutzer nicht sie in dem Eingangsformat festsetzen müssen. Jeder Wert, der in dem Eingangsmakroblock-Kopfwort spezifi ziert wird, wird durch den BP ignoriert.

10.8.5.2 Bewegungsdatenwort

Jeder Makroblockkopf sollte zusätzliche Kopfdaten haben, wenn der Makroblock Bewegungsvektoren beinhaltet. Lassen sie uns als erstes den Fall von MPEG-1 und MPEG-2 betrachten. Diese Standards werden das zusätzliche Kopfwortformat, das in Ta belle 36 für die Bewegungsvektoren gezeigt ist, haben, wenn einer der folgenden Fälle vorliegt:
Zustand 1), wenn MF = 1 oder (I = 1 und CMV = 1)
Zustand 2), wenn MB = 1

Allgemeines Bewegungsvektor-Datenformat für MPEG-1 und MPEG-2

In Tabelle 36 sind alle Komponentenwerte von Halb-Bildele mentgenauigkeit. Die FS0, FS1, FS2 und FS3 sind 1 Bit- Markierungen, um die Feldauswahl für jeden Bewegungsvektor zu melden. Wenn keine Feldauswahl existiert, so sollte die Mar kierung auf 0 gesetzt werden. Da der MPEG-1 nicht die Feld auswahlinformation benutzt, sollten solche Markierungen auf 0 gesetzt werden.

Ein Ausnahmefall passiert bei der MPEG-2 Codierung für Dual- Prim-Bewegungsvektoren. In diesem Fall besteht der Vorwärts bewegungsvektor aus 16 Bytes (eigentlich werden die 8 Bytes benutzt) und das Format sollte wie in Tabelle 37 sein. Norma lerweise wird der BP den Bewegungsvektorwert auf einen diffe rentiellen Wert in der Video-Codierungsanwendung umwandeln. Jedoch sollte die Bewegungsvektorkomponente in der Tabelle 37 der differentielle Wert sein, welcher der Eingang des Huff man-Codierers ist. Die Dual-Prim-Bewegungsvektoren werden al le durch den BP im Falle der MPEG-2 Decodierungsanwendung ge handhabt.

Bewegungsvektor-Datenformat im Dual-Prim-Modus für MPEG-2 Codierung

H.261 und H.263 werden etwas verschiedene Bewegungsvektorda tenformate haben. Am allermeisten wird ein Einzelbyte für je den Bewegungsvektorkomponentenwert ausreichend sein. Abhängig von den Inhalten der MF- und M4-Markierungen wird der korre spondierende Bewegungs-kompensierte Makroblock mindestens 2 und höchstens 10 Bewegungsvektorkomponenten haben. Das Daten format für die Bewegungsvektordaten wird in Tabelle 38 ge zeigt.

Bewegungsvektordatenformat für H.261 und H.263

10.8.5.3 Pixelkoeffizienten-Datenwort

Die vier Video-Komprimierungsstandards haben eine unter schiedliche maximale Pixel-Bitlänge für das Quantisierungsni veau. Der Vergleich wird in Tabelle 39 gemacht.

Eingangs- und Ausgangs-Pixel-Bitauflösung

Deshalb ist das Pixel-Datenformat für MPEG und Video- Konferenzstandards verschieden, wie wir von Tabelle 40 sehen können.

Pixel-Koeffizientendatenformat

10.9 Unterbrechungszustände

Der BP unterbricht die ARM7 durch Geltendmachung der ARM7_IRQ-Markierung, wenn er die Unterbrechungsbedingungen trifft, die in diesem Abschnitt beschrieben sind. Der BP hat zwei Sätze von Unterbrechungsbedingungen, die Standard- und die Fehlerbedingungen. Diese Bedingungen werden alle in dem BP_STATUS[15 : 0] gespeichert. Wenn irgendein Bit durch den BP gesetzt wird, so wird es das ARM7_IRQ Signal aktivieren. Die se Zustände sind alle maskierbar durch Setzen des korrespon dierenden Bits des BP_INT_MASK[15 : 0]-Registers.

10.9.1 Standard-Unterbrechungszustände

- Standard-Zustand 0 (BP_STATUS[0]) - wenn das Verarbeiten des Eingangspuffers 0 beendet wird, so sollte der BP das ARM7_IRQ aktivieren, ebenso wie das Setzen der IBUF0_DONE-Markierung.
- Standard-Zustand 1 (BP_STATUS[1]) - wenn die Verarbei tung des Eingangspuffers 1 beendet wird, so sollte der BP das ARM7_IRQ aktivieren, ebenso wie das Setzen der IBUF1_DONE Markierung.
- Standard-Zustand 2 (BP_STATUS[2]) - wenn die Verarbei tung des Ausgangspuffers 0 beendet wird, so sollte der BP das ARM7_IRQ aktivieren, ebenso das Festsetzen der OBUF0_FULL Markierung.
- Standard-Zustand 3 (BP_STATUS[3]) - wenn die Verarbei tung des Ausgangspuffers 1 beendet wird, so sollte der BP das ARM7_IRQ aktivieren, ebenso wie das Festsetzen der OBUF1_FULL Markierung.
- Standardzustand 4 (BP_STATUS[4]) - wenn das Slice (Scheibe) oder die GOB, die durch die ARM7 bestimmt wird, im Falle der Video-Codierung beendet werden, oder wenn die Nicht-Scheiben- oder Nicht-GOB-Startcodes im Falle der Video-Decodierung erreicht werden, so sollte der BP das ARM7_IRQ aktivieren, ebenso wie das Festset zen der BP_DONE-Markierung.
- Standardzustand 5 (BP_STATUS[5]) - wenn die Kontextsi cherungsfunktion in dem präemptiven Kontextschaltungsmo dus beendet wird oder wenn das aktuelle Slice (Scheibe) oder die GOB im kooperativen Kontextschaltungsmodus be endet wird, so sollte der BP das ARM7_IRQ aktivieren, ebenso wie das Setzen der CTX_SW_DONE-Markierung.
- Standardzustand 6 (BP_STATUS[6]) - wenn die Kontextwie derladefunktion beendet wird, so sollte der BP das ARM7_IRQ aktivieren, ebenso wie das Setzen der CTX_RELOAD_DONE-Markierung.
- Standardzustand 7 (BP_STATUS[7]) - momentan ist der BP_STATUS [7] reserviert. Daher muß dieses Bit auf "0" gesetzt werden.

Normalerweise wird nicht empfohlen, diese Standard- Unterbrechungszustände durch Benutzen von BP_INT_MASK[7 : 0] zu maskieren. Jedoch können in einigen Anwendungen die Benutzer den Standardzustand 1 maskieren wollen.

10.9.2 Fehlerunterbrechungszustände

Wenn ein Fehler in dem BP auftrat, so setzt der BP die BP_ERR-Markierung, welche in einer ARM7 Unterbrechungsanfrage resultieren wird. Gleichzeitig setzt der BP geeignete Daten von einem Nicht-Nullwert in dem BP_ERR_CODE-Feld im BP_STATUS-Register. Dieser 8-Bit BP_ERR_CODE hat die folgen den Bedeutungen:

- BP_ERR_CODE = 8'b0000_0000; keine Fehler traten auf.
- BP_ERR_CODE = 8'b0000_0001; illegales Setzen des BP_MODE Registers.
- BP_ERR_CODE = 8'b0000_0010: Illegale horizontale Makro blockposition ist gesetzt.
- BP_ERR_CODE = 8'b0000_0011: Illegale vertikale Makro blockposition ist gesetzt.
- BP_ERR_CODE = 8'b0000_0100: illegales VLC für die Makro blockadressenzunahme.
- BP_ERR_CODE = 8'b0000_0101: illegales VLC für Makro blocktyp.
- BP_ERR_CODE = 8'b0000_0110: illegales VLC für Makro blockbewegungscode.
- BP_ERR_CODE = 8'b0000_0111: illegales Verbergungs- Bewegungsvektormarkierungsbit.
- BP_ERR_CODE = 8'b0000_1000: illegales VLC für codiertes Blockmuster.
- BP_ERR_CODE = 8'b0000_1001: illegales VLC für Block DCT dc Größe.
- BP_ERR_CODE = 8'b0000_1010: illegaler DCT dc Wert.
- BP_ERR_CODE = 8'b0000_1011: illegales VLC für Block DCT ac Koeffizient.
- BP_ERR_CODE = 8'b0000_1100: # an Blocks in einem Makro block überschreitet 64.
- BP_ERR_CODE = 8'b0000_1101: illegaler f_code Wert (d. h. der Wert ist Null)
- BP_ERR_CODE = 8'b0000_1110: illegales VLC für Block DCT ac Koeffizient.
- BP_ERR_CODE = 8'b0000_1111: illegales IBUF und OBUF Adressensetzen.
- BP_ERR_CODE = 8'b0001_0000: Die niedrigstwertigen 4 Bits einer Startadresse für den BP Eingangs- und Ausgangspuf fer sind nicht gleich Null.
- Andere BP_ERR_CODE Werte werden reserviert.

10.10 Detaillierte funktionelle Erfordernisse 10.10.1 IOBUS Schnittstelle

Alle Datenbewegungen zwischen dem BP und der CCU gehen über den IOBUS. Der IOBUS ist ein 32-Bit @ 4,0 MHz synchroner Bus, der die multiplexierten Adressen und Daten enthält. Da minde stens 7 Zyklen erforderlich sind, um 16 Byte-Adressen über den IOBUS zu übertragen, wird die maximale Übertragungsrate jedoch des IOBUS 91,4 Mbytes/s (= 731,4 Mbits/s) sein.

Der BP kann entweder Master oder Slave für alle IOBUS-Lese- und Schreibebewegungen sein. Wenn der BP als Master funktio niert, so muß er ein Anfragesignal an die IOBUS- Entsscheidungseinheit senden. Wenn der IOBUS frei ist, so wird die Entscheidungseinheit eine Bewilligung und eine Vor richtungsauswahl an den BP senden.

Der Dateninhalt über den IOBUS kann einer von den folgenden drei Kategorien sein: 32 Bit-Pixel-Daten, die zwei oder vier Pixel-Komponenten enthalten, 32 Bit komprimiertes Bitstrom wort, und Syntax/Steuerungsparameter für die Codierungs- und Decodierungsfunktionen. Für weitere Informationen über die IOBUS Schnittstelle, wie Zeitsteuerungsdiagramme, wird dem Leser empfohlen, die MSP IOBUS Spezifikation anzuschauen.

10.10.2 Blockschichtverarbeitung 10.10.2.1 Zickzack-Scan-Konvention

Der BP unterstützt die zwei Zickzack-Scan- Konvertierungsmatrizen, welche in dem MPEG Video-Standard vorgeschlagen werden. Die 8×8 Blockdaten, welche zwischen dem VP und dem BP übertragen werden, müssen alle 64 Komponen ten enthalten.

10.10.2.2 RLC-Code

Für die RLC-Decodierung erzeugt der BP Null- und Niveaudaten entsprechend dem Huffman-decodierten Ergebnis der DCT ac Koeffizienten. Wenn das end_of_block-Signal erfaßt wird, be vor die 64 Pixeldaten für einen 8×8 Block erzeugt werden, so ist der RLC-Decodierer dafür verantwortlich, die verblei benden Nulldaten herzustellen.

Für die RLC-Codierung zählt der BP die Anzahl der benachbar ten Null-Daten und stellt die Lauflänge und den Ni veau(pegel)code durch Kombinieren mit den nächsten Nicht- Nulldaten her. Wenn die verbleibenden Daten alle gleich Null sind, so sollte er das end_of_block-Signal erzeugen anstelle des Herstellens des RLC für die verbleibenden Daten. Der Ver arbeitungszyklus für einen RLC-Code ist derselbe wie die An zahl der Nullen, die zu erzeugen sind.

10.10.2.3 Huffman-Code

Der BP Huffman-Code unterstützt alle Huffman-Tabellen, welche in dem MPEG-1, MPEG-2, H.261 und dem H.263 Video-Standard empfohlen werden. Es wird angenommen, daß die meisten Tabel len in dem Tabellen-ROM implementiert werden, wo jedes ROM- Wort 12 Bit breit ist. Jedoch werden einige Huffman-Tabellen, welche als einfach seiend oder ziemlich kompliziert seiend empfunden werden, durch Benutzen der fest-verdrahteten Logi ken implementiert. Die Decodierer-Tabellen, die implementiert werden sollten durch Benutzen des Tabellen-ROM, werden in Ta belle 41 zusammengefaßt.

Erforderliche ROM-Größe für Huffman-Decodierer-Tabellen

Die Codierer-Tabellen werden in Tabelle 42 zusammengefaßt, welche ein größere ROM-Größe als die Decodierer-Tabellen er fordert.

Erforderliche ROM-Größe für Huffman-Codierertabellen

Von den Tabellen 41 und 42 sehen wir, daß die erforderliche Gesamt-ROM-Größe für den Huffman-Codierer und -Decodierer 768×12 Bits ist. Die obigen Tabellen beinhalten nicht den Fül lungscode, den escape_code, das Vorzeichenbit des DCT Koeffi zienten und den end_of_block-Code, welche durch die Zustands maschine gehandhabt werden.

Die Verarbeitungszyklen für jeden der Huffman-Codes werden in Tabelle 43 aufgelistet.

Verarbeitungszyklen für Huffman-Codes

Schließlich ist anzumerken, daß die Implementierung der JPEG- Decodierungstabellen nicht vorgenommen werden kann, wenn wir diese Näherung benutzen. Jedoch ist anzumerken, daß die dc_coeff_next_0-Tabelle für JPEG-Codierungsanwendungen be nutzt werden kann.

10.10.2.4 dc Differential-Werte

Im Falle der intra-Blocks berechnet der BP ebenso den Diffe rential-dc-Koeffizienten für die erste Komponente der 8×8 Blockdaten und rekonstruiert den dc Wert mit dem übertragenen Differential-dc-Koeffizienten.

10.10.2.5 Nicht-codierte Blocks

Der BP unterstützt nicht die Blocks, welche nicht codiert sind. Der VP und die ARM7 sind dafür verantwortlich, den nicht-codierten Block zu verarbeiten. Um den VP und die ARM7 es zu überlassen, diese Art von Blocks zu handhaben, zeigt der BP die nicht-codierten Blocks in dem coded_block_pattern (codiertes_block_muster) an, welches in den Makroblock- Kopfwörtern erscheint.

10.10.2.6 Reihenfolge der Blocksendung

Es ist anzumerken, daß die Reihenfolge der Blöcke in einem Makroblock, die für sowohl die Codierung als auch die Deco dierung gesendet werden, gleich wie folgt ist: Luminanz (Y) Block 0, 1, 2 und 3, Chrominanz blau (Cb) Block und Chromi nanz rot (Cr) block.

10.10.3 Makroblockschicht-Verarbeitung 10.10.3. 1 Differentialbewegungsvektoren

Der BP berechnet den Differentialbewegungsvektor aus dem Be wegungsbewertungsergebnis und rekonstruiert den Bewegungsvek tor mit dem gesendeten Differentialbewegungsvektor mit Aus nahme der folgenden Fälle.

- Der erste Fall ist der Dual-Prim-Modus des MPEG-2 Video- Codierungsfalles. In diesem Fall sollten die Bewegungs vektoren, die zu dem BP gesendet werden, von der Vek tor' [0] [0] [1 : 0] Form sein, nicht von der Vektorform' [r] [0] [1 : 0] (siehe Abschnitt 7.6.3.6 des MPEG-2 Video- Standards).
2. Der zweite Fall ist der vorangeschrittene Voraussagemo dus des H.263. In diesem Modus können wir vier Bewe gungsvektoren haben, und diese Werte sollten von/zu dem BP als differentielle Werte gesendet werden.

10.10.3.2 Übersprungene Makroblocks

Der BP unterstützt nicht die übersprungenen Makroblocks. Der VP und die ARM7 sind dafür verantwortlich, diese übersprunge nen Makroblocks zu verarbeiten. Um dem VP und der ARM7 zu er möglichen, die übersprungenen Makroblocks zu handhaben, schreibt der BP die horizontalen und vertikalen Makroblock adressen in die Makroblockkopfwörter.

10.10.3.3 Makroblock-Füllungscodes

Bei dem MPEG-1 Decodieren gibt der BP den Makroblock- Füllungscode in einem Zyklus ab, wenn er existiert. Bei dem MPEG-1 Codieren erlaubt jedoch der BP dem Benutzer nicht, die Makroblock-Füllungscodes in den Makroblock-Schichtkopf hin einzunehmen. Im allgemeinen wird dieser Füllungscode benutzt, um den Ausgangs-Video-Vorlaufpuffer zu steuern. Somit wird empfohlen, Null-Füllungsbits zwischen den Startcodes einzu setzen anstelle des Einsetzens der Makroblock-Füllungscodes.

10.10.4 Slice (Scheiben)- oder GOB-Schichtverarbeitung 10.10.4.1 Byte-Ausrichtung

Für die MPEG-1 und MPEG-2 Anwendungen soll der Bitstromaus gang bis zu der Scheibenschicht Byte-ausgerichtet sein. Für die H.263 Anwendung kann der Bitstromausgang zu der GOB- Schicht Byte-ausgerichtet sein, obwohl der Bitstromausgang zu der Bildschicht Byte-ausgerichtet sein soll. Jedoch wird der Ausgang des H.261 Codierers nicht Byte-ausgerichtet sein. Da her sollte die Bitstrom-Bildungsroutine in der ARM7 vorsich tig durch Berücksichtigung dieser Unterschiede programmiert werden. Der BP führt automatisch Null-Füllung an dem Ende der Scheibe durch, wenn der Betrag an Daten für die letzte Daten übertragung über den IOBUS weniger als 16 Bytes im Falle der Codierung ist.

10.10.4.2. Extra-Slice(Scheiben)information

Beim Decodieren wird jede Extra-Scheibeninformation, welche in dem Scheibenkopf des MPEG-1 oder MPEG-2 Bitstromes enthal ten sein kann, vom BP abgegeben. Beim Codieren setzt der BP nicht irgendeine Extra-Scheibeninformation ein, welches durch einen Benutzer angefragt werden kann. Wenn der Benutzer immer noch die Information in dem MPEG-1 oder MPEG-2 Bitstrom mit einschließen muß, so kann er die Information in dem Bitstrom einsetzen, welcher schon durch den BP codiert worden ist.

10.10.4.3 Intra_Slice(Scheibe)

In dem MPEL-2 Scheibenschicht-Bitstrom wird ein Parameter, der intra slice genannt wird, benutzt, um zu melden, daß die momentane Scheibe nur aus intra Makroblocks besteht. Diese Information wird nicht in dem Decodierungsprozeß benutzt und dient dazu, einer DSM-Anwendung beim Durchführen schneller Vorwärts- und schneller Rückwärtsfunktionen zu helfen. Daher gibt der BP diese Information bei der Decodierungsanwendung ab und setzt intra_slice auf 0 in dem Scheibenschichtkopf bei der Codierungsanwendung.

10.10.4.4 Scheiben- oder GOB Startcodes

In dem MPEG-1, MPEG-2 und H.261 muß jedes Bild mindestens ei nen Scheiben- oder einen GOB-Startcode haben. Jedoch kann ein H.263 Bild nicht den GOB Startcode und die Kopfinformation haben. Insbesondere soll die erste GOB in jedem H.263 Bild nicht den Startcode und die Kopfinformation beinhalten. De halb muß die BP Zustandsmaschine die Makroblockschicht direkt handhaben, wenn der eingehende Bitstrom für H.263 ist. Zu sätzlich, wenn ein GOB Startcode gefunden wird, während der Bitstrom decodiert wird, dann hat der BP den Startcode zu de codieren und seine Verarbeitung weiterzuführen, ohne die ARM7 zu unterbrechen.

10.11 Eingangs/Ausgangs-Doppelpufferschnittstelle 10.11.1 Allgemeine Beschreibung

Die Eingangs- und Ausgangspuffer müssen durch den Doppelpuf fer implementiert werden. Somit haben wir eigentlich vier Speicherpuffer, die IBUF0, IBUF1, OBUF0 und OBUF1 heißen, wie dies in den Fig. 64 und 65 gezeigt wird.

Wie man aus den Fig. 64 und 65 sehen kann, hat jeder Puffer Start- und Endadressen und "voll(full)" und "getan(done)"- Markierungen. Um jede Puffergröße zu bestimmen, sollten die Benutzer die geeigneten Werte in die Start- und Endadressen register für jeden Puffer schreiben.

Sobald der Quellenprozessor für den Puffer das Schreiben des Puffers vollendet hat, sollte er die "voll"-Markierung setzen und anfangen, in die andere Bank zu schreiben. Wenn der Sen ke-Prozessor für die Bank findet, daß die Bank, auf die zuzu greifen ist, voll ist, so liest er die Daten. Wenn die Bank leer wird, sollte die Senke die "getan"-Markierung setzen und die "voll"-Markierung der anderen Bank überprüfen.

Die vier Startadressen werden durch den BP aktualisiert, wie es in dem Unterabschnitt 10.7.2 beschrieben wird. Jedes Regi ster für die Startadresse wird die letzte Byte-Adresse ent halten, auf die durch den BP zugegriffen wird, wann immer der BP auf den Eingangs- oder Ausgangspuffer zugreift. Deshalb sollte die ARM7 die korrespondierende Startadresse wieder setzen, wenn sie heraus findet, daß irgendeine der IBUF0_DONE, IBUF1_DONE, OBUF0_FULL und OBUF1_FULL Markierungen gesetzt ist.

Es ist ebenso anzumerken, daß die letzten vier Bits für die Startadresse immer alle auf Null durch die ARM7 gesetzt wer den sollten. Dies ist aufgrund einer internen Datenausrich tungsstruktur zwischen dem FBUS, der CCU und dem IOBUS. Es ist ebenso erforderlich, jede der Endadressen so zu setzen, daß die Gesamtzahl an Bytes für jede Puffergröße ein Vielfa ches von 16 sein kann. Zusätzlich ist es zu empfehlen, daß die minimale Puffergröße 64 Bytes für den MPEG-1 und den MPEG-2 und 128 Bytes für H.261 und H.263 sein soll. Dies ist, um eine Leistungsverschlechterung aufgrund der häufigen Un terbrechungsanfragen an den ARM7 durch den BP zu verhindern.

10.11.2 Handhabung des abnormalen Pufferstatusses

Wenn beide Ausgangspuffer voll sind, so muß der BP seine Ver arbeitung stoppen und fällt in einen Leerlaufzustand, unab hängig von dem Eingangs-Doppelpufferstatus. Der BP sollte au tomatisch aus diesem Leerlaufzustand aufwachen, wenn die OBUF0_DONE- oder OBUF1_DONE- Markierung gesetzt wird.

Wenn beide Eingangspuffer leer sind, so braucht der BP nicht unmittelbar stoppen, und er kann in seiner Verarbeitung wei terfahren, bis er die Verarbeitung der internen verbleibenden Daten vollendet hat. Jedoch wird der BP die ARM7 sofort un terbrechen, wenn beide Eingangspuffer leer sind. Nach Ver vollständigung der verbleibenden Datenverarbeitung und wenn die Eingangspuffer immer noch als leer vorgefunden werden, hat der BP in den Leerlaufzustand zu fallen. Wiederum sollte der BP automatisch aufwachen, wenn IBUF0_FULL oder IBUF1_FULL gesetzt sind.

Der Leerlaufzustand, der in diesem Unterabschnitt beschrieben wird, ist verschieden von den anderen Leerlaufzuständen, die in dieser Beschreibung beschrieben werden, da das Aufwachen aus anderen Leerlaufzuständen im allgemeinen einen Steue rungsbefehl der ARM7 erfordert.

10.11.3 Physikalische Implementierung des I/O Puffers: Bei spiel

Allermeistens liegt es in der Verantwortlichkeit des Benut zers, den Ort und die Größe des BP Eingangs- und Ausgangspuf fers festzulegen. Die Benutzer können die Puffer in dem Zwi schenspeicher- bzw. Notizblockspeicherbereich des VP Daten cache, des ARM7 Datencache oder des SDRAM implementieren. Ob wohl die Implementierung des BP Eingangs- und Ausgangsdoppel puffers irgendwie eingeschränkt erscheint, kann es einen lei stungsfähigen Weg zum Implementieren der obigen Puffer geben.

Nun laßt uns ein spezielles Beispiel für die Implementierung eines Raten-bzw. Vorhaltepuffers in einer Video- Decodierungsanwendung betrachten. In diesem Fall kann der Be nutzer es wollen, einen zirkularen Puffer für den BP Ein gangspuffer zu implementieren. Hier wird angenommen, daß wir den SDRAM benutzen, und der volle Ratenpuffer wird in vier Blöcke aufgeteilt, wie es in Fig. 66 gezeigt ist.

Anfänglich kann der Benutzer rate_buffer_block_0 und ra te_buffer_block_1 jeweils auf IBUF0 und IBUF1 setzen.

Dies kann durch Setzen wie folgt durchgeführt werden:
IBUF0_START = Rate_Buffer_Address_0;
IBUF0_ENDE = Rate_Buffer_Address_1;
IBUF1_START = Rate_Buffer_Address_2;
IBUF1_ENDE = Rate_Buffer_Address_3;

Nachdem die Daten in dem IBUF0 (d. h. die Daten in dem Ra te_Buffer_Block_0) alle durch den BP verbraucht sind, wird der BP die ARM7 unterbrechen. Dann kann die ARM7 Rate_Buffer_Block_2 als IBUF0 durch Setzen wie folgt festset zen:
IBUF0_START = Rate_Buffer_Address_4;
IBUF0_END = Rate_Buffer_Address_5;

Nachdem die Daten in Rate_Buffer_Block_1 alle durch den BP verbraucht sind, wird er wiederum unterbrechen, und die ARM7 kann Rate_Buffer-Block_3 als IBUF1 durch Setzen wie folgt festsetzen:
IBUF1_START = Rate_Buffer_Address_6;
IBUF1_ENDE = Rate_Buffer_Address_7;

Nachdem die Daten in dem Rate_Buffer_Block 2 alle durch die BP verbraucht sind, kann die ARM7 den Rate_Buffer_Block_0 als das IBUF0 wiederum durch Festsetzen der Adresse, wie in dem ersten Schritt, festsetzen.

Somit kann die zirkulare Pufferimplementierung durch einfa ches Wiederholen dieses kompletten Ablaufes durchgeführt wer den. Dieses Beispiel zeigt, daß der Gebrauch des BP Doppel puffers ziemlich flexibel abhängig von der Absicht des Ge brauchers sein kann.

10.12 Kontextschaltung

Wenn mehr als eine Anwendung auf dem MSP laufen soll, so wird das ARM7 Betriebssystem den BP anweisen, den aktuellen Task zu beenden und zu einem anderen Task umzuschalten. Dieser Ab lauf wird normalerweise als "Kontextumschaltung" bezeichnet. Der BP unterstützt zwei Arten von Kontextumschaltungsmoden, welche in dem Folgenden beschrieben werden.

10.12.1 Präemptive Kontextumschaltung

Die präemptive Kontextumschaltung besagt, daß der BP die Ver arbeitung des aktuellen 8×8 Pixel-Blockes durchführen soll und dann die normale Verarbeitung beenden soll. Die ARM7 kann den präemptiven Kontextumschaltungsmodus durch Setzen der CTX_SWITCH und CTX_MODE-Markierungen in dem BP_CONTROL[6 : 5]- Register als "11" anweisen. Wenn die aktuellere Blockverar beitung vollendet ist, soll der BP den internen Kontext an den externen SDRAM für zukünftige Verarbeitung senden.

Wenn der BP die Kontextsicherung beendet, soll er die ARM7 mit Setzen der CTX_SW_DONE-Markierung, die in dem BP_STATUS [5] angeordnet ist, unterbrechen. Dann soll die ARM7 alle Inhalte von dem Eingangs- und Ausgangspuffer des NP si chern und den BP für andere Tasks initialisieren.

Dieser Modus ist dafür da, um den BP auf die Kontextumschal tungsanfrage des ARM7 so bald wie möglich antworten zu las sen. Im schlimmsten Fall wird der BP ungefähr 150 Zyklen (= 3,75 µs) benötigen, um die aktuelle Blockverarbeitung zu vollenden. In normalen Fällen jedoch ist es durchaus vernünf tig, anzunehmen, daß wenige Dutzende von Zyklen erforderlich sein werden, um die Blockverarbeitung zu vollenden.

10.12.2 Kooperative Kontextumschaltung

Die kooperative Kontextumschaltung ist dafür da, um den Kon textsicherungsablauf für den BP zu eliminieren. Dies kann aufgrund der Tatsache erreicht werden, daß jede Sli ce(Scheiben)- oder GOB-Schichtverarbeitung die vollen BP in ternen Zustände initialisieren muß. In diesem Modus fährt der BP mit seiner normalen Verarbeitung der aktuellen Scheibe oder GOB fort und beendet dann die Verarbeitung.

Die ARM7 kann den kooperativen Kontextumschaltungsmodus durch Setzen der CTX_SWITCH und CTX_MODE-Markierungen in dem BP_CONTROL[6 : 5] auf "10" anweisen. Wenn die momentane Schei ben- oder GOB-Verarbeitung vollendet wird, so wird der BP die ARM7 mit Setzen der CTX_SW_DONE-Markierung, die in dem BP_STATUS[5] angeordnet ist, unterbrechen. Dann muß die RAM7 alle Inhalte der Eingangs- und Ausgangspuffer des BP sichern und den BP für andere Tasks initialisieren.

10.12.3 Kontextwiederladung

Um zum vorherigen Task umzuschalten, sollte der BP den Kon text wieder laden, der in dem SDRAM von der Adresse SAVE_ADR[31 : 0] gesichert ist.

Um diese Kontextwiederladung anzufragen, ist es erforderlich, daß der BP in dem Leerlaufzustand ist. Die möglichen Situa tionen für diese Anfrage werden sein, wenn das BP_DONE ge setzt ist, wenn das CTX_DONE gesetzt ist oder wenn die ARM7 den BP mit der Software zurücksetzt. Daher wird, wenn die ARM7 die CTX_RELOAD-Markierung in BP_CONTROL[7] setzt, der BP von dem Leerlaufzustand aufwachen und beginnen, den gesicher ten Kontext zu lesen.

Nachdem der BP den Kontextwiederladebetrieb beendet hat, un terbricht der BP die ARM7 mit Setzen der CTX_RELOAD(Wiederladen) _DONE-Markierung. Dann muß die ARM7 die BP internen Register initialisieren und schaltet den BP für die vorangegangene Task-Verarbeitung ein.

10.13 Job-Quittungsbetrieb

Dieser Abschnitt deckt den detaillierten Ablauf für den Job- Quittungsbetrieb ab, wenn der BP die Verarbeitung vollendet. Hier bedeutet das "Aktualisieren des Zeigers für die letzten Daten", daß der BP die geeigneten Werte zu VALID_BYTE_ADR[31 : 0] und VALID_BYTE_POS[2 : 0] jeweils schreibt.

10.13.1 Codierungsfall

Normalerweise werden die Eingangsdaten für die Codierung von dem VP zugeführt. Wenn einer der Eingangsdoppelpuffer durch den VP voll ist, so startet der BP das Lesen der Daten über den IOBUS. Wenn das Ende der Verarbeitung erreicht wird (d. h. die Anzahl der verarbeiteten Makroblocks ist gleich der An zahl der Makroblocks, die durch die ARM7 bezeichnet werden), dann hat der BP die ARM7 mit Setzen der BP_DONE-Markierung zu unterbrechen und fällt in den Leerlaufzustand.

Der Zeiger für die gültigen Daten sollte das "Ende des kom primierten Bitstromes" für die Scheibe oder die GOB anzeigen. Zusätzlich sollte VALID_BYTE_ADR[31 : 0] eine Position in einem der Ausgangsdoppelpuffer anzeigen.

Die ARM7 bildet den endgültigen Bitstrom durch Kombinieren dieses komprimierten Bitstromes und der Oberschichtköpfe und wiederholt den Ablauf. Wenn die ARM7 es will, den BP wieder zustarten, bevor er komplett die Daten in dem Ausgangsdoppel puffer verbraucht, kann dies durch Verbrauchen von mindestens einem Ausgangsdoppelpuffer und durch Sichern des Zeigers für die letzten Daten erreicht werden, da der Zeiger durch die BP aktualisiert wird, wenn er wieder gestartet wird.

10.13.2 Decodierungsfall

Als erstes sucht die ARM7 den Scheiben- oder GOB-Startcode (wenn vorhanden). Wenn der Startcode gefunden ist, so initia lisiert und schaltet die ARM7 den BP ein. Nachdem der BP die Huffman-Decodierung, die RLC-Decodierung und die inverse Zickzack-Scan-Umwandlung durchgeführt hat, werden die Daten an den Ausgangspuffer für die VP-Verarbeitung gesendet. Der BP fährt mit dieser Verarbeitungsroutine fort, bis ein Nicht- Scheiben- oder Nicht-GOB-Startcode erfaßt wird. Wenn sie er faßt werden, unterbricht der BP die ARM7 mit Setzen des Zei gers für die letzten Daten, die für das "Ende des Nicht- Scheiben- oder Nicht-GOB-Startcodes" benutzt werden. Die ARM7 muß dann den Startcode decodieren und das Kopf-Parsing durch führen, bis der nächste Scheiben- oder GOB-Startcode gefunden wird.

10.13.3 Fehlerfund in dem komprimierten Bitstrom

Bei der Video-Konferenzanwendung, wo die eigentlichen Daten über die Telefonleitung oder das öffentliche Schaltungsnetz werk gesendet werden, würde es höchstwahrscheinlich sein, daß einige ungültige Daten in den einkommenden Bitstrom einge schlossen sind. In diesem Fall muß der BP die ARM7 unterbre chen und den Inhalt der ERR_HANDLE_MODE-Markierung überprü fen. Es würde sicher sein, wenn die Benutzer sich für den Fehlerhandhabungsmodus entscheiden, bevor der BP für die spe zifische Anwendung eingeschaltet wird.

Wenn die ERR_HANDLE_MODE-Markierung auf "1" gesetzt wird, so findet der BP automatisch den nächsten Startcode. Wenn der Startcode für eine Scheibe oder ein GOB ist, so fährt der BP mit seiner normalen Verarbeitung fort. Dieser Modus ist ziem lich leistungsstark, da der BP einen Startcode schneller fin den kann als die ARM7, und die ARM7 kann andere Verarbei tungsroutinen durchführen, während der BP den nächsten Start code findet. Jedoch, wenn ein Startcode von einer anderen als der Scheiben- oder GOB-Schicht gefunden wird, sollte der BP die ARM7 wiederum mit Setzen der BP_DONE-Markierung unterbre chen und in den Leerlaufzustand fallen. In diesem Fall muß der Zeiger für die letzten Daten, die benutzt werden, das En de des nächsten Startcodes anzeigen.

Wenn die ERR_HANDLE_MODE Markierung auf "0" gesetzt wird, so muß der BP in den Leerlaufzustand fallen, ohne den nächsten Startcode zu suchen. In diesem Fall muß der Zeiger für die letztbenutzten Daten die Position anzeigen, bei welcher der Fehler gefunden wird. Dieser Modus wird nützlich sein, wenn die Benutzer einen kontaminierten Bitstrom, der die ARM7 Be fehle benutzt, austesten wollen.

Anhang B MPC BITSTROMPROZESSOR

Der Bistromprozessor (BP) ist einer der eine Schlüsselstellung einnehmenden MSP Verarbeitungskerne für Videodaten-Codierungs- und -Decodierungsanwendungen. Der BP deckt die MPEG Scheibenschichtcodierung und -decodierung und die H.261/H.283 Gruppenblock-(GOB)-Schichtcodierung und -decodierung ab. Bei den Decodierungsanwendungen liefert der BP die komplette Information, die in jedem Makroblock enthalten ist, an entweder den Vektorprozessor oder den ARM7 Kern.

Die Bistromprozessor-Hardware wird in 4 funktionelle Blöcke aufgeteilt:

- IOBus Anschlußschnittstelle einschließlich der IO Steuerung und Decodierungseinheiten
- BP Steuerungszustandsmaschine
- Codec Kern einschließlich den BP Registermultiplexern und Registern, der arithmetischen logischen Einheit und dem Multiplexer, und der FIFO Steuerungseinheit
- die VLC FIFO Einheit
- die VLC Codec einschließlich dem Tabellen-ROM mit dem Codec-Adressengenerator

Der VLC LUT ROM 340 (Fig. 3) wird unmittelbar unten beschrieben werden.

1.0 Methodenlehre

Die Tabelleneinheit ist Kern der Huffman-Codierung und -Decodierung. Diese Einheit unterstützt alle VLC Tabellen, welche in den MPEG-1, MPEG-2, H.261 und H.263 Beschreibungen beinhaltet sind und durch den SAMSUNG MSP unterstützt werden. Die meisten dieser Tabellen werden in dem ROM implementiert, welcher 12 Bit breit ist. Jedoch, wenn der Suchablauf zu einfach ist oder nicht mit der Größe der ROM- Tabelle übereinstimmt, dann wird eine spezielle Codierung/Decodierung angewendet. Alle vier Spezifikationen in dieser Schicht enthalten viele veränderbare Längencodes bis zu 17 Bits. Neben dem codierten oder decodierten Wert wird die Codegröße und der gültige Code-Indikator für die Codierung und die Decodierung geliefert, um den Prozeß korrekt zu betreiben. Wenn wir die traditionelle Methode benutzen, um die VLC-Tabellen zu codieren und decodieren, so werden die ROM-Tabelle und der Adressengenerator wesentlich größer sein. 1.1 Implementierungsstrategie kann beschrieben werden wie:

- Gemeinsam benutzte ROM-Tabellen so viel wie möglich, wenn es den Adressengenerator nicht schwieriger macht;
- Wiederanordnen der VLC-Tabellen basierend auf der Codierung und Decodierung;
- Null-Zählungen oder eine Zählung, welche auf dem Huffman-Code basieren, zuerst decodieren;
- Reduzieren der Tabellengröße durch Benutzen einer Bitmarkierung, wie das Vorzeichen oder gerade/ungerade;
- Aufteilen einer ROM-Anordnung in hoch und tief, wenn möglich;
- Benutzen des LSBs der VLC, um die ROM-Tabellenadresse zu erzeugen, um den Adressengenerator zu vereinfachen.

Dieses Verfahren ist sehr leistungsstark. Die endgültige ROM- Tabellengröße beträgt 768×12 Bits, welche wesentlich kleiner als diejenige ist, die durch das Problem beschrieben wird.

Das Nachschlagen wird durch einen ROM-Tabellenadressen generator und eine ROM-Tabellennachschlageprozedur durchgeführt. Der Adressengenerator decodiert die Eingangssignale, wie den Tabellentyp, den Modus und den VLC/Wert und erzeugt die Adresse der ROM-Tabelle. Dann können die codierten und decodierten Daten von dem ROM-Tabellenwert und anderen Informationen hergeleitet werden. Die Decodierungstabelle hat zwei Formate. Das erste wird auf die DCT-Koeffizienten angewendet, welche einen ROM-Speicherstelle pro VLC-Code haben. Das andere Format wird auf andere Tabellen angewendet, in welchen jede ROM-Speicherstelle in die oberen 6 Bits und die unteren 6 Bits aufgesplittet ist. Deshalb enthält jede Speicherstelle zwei VLC-Codes. Die Codierungstabelle hat zwei Formate. Eines ist für TCOEF von H.263. Das andere ist für die anderen Tabellen. Jede ROM- Speicherstelle enthält einen Huffman-Code für Codierungsanwendungen. Die Größe der ROM-Tabelle ist 768×12 Bits. Die Tabelle kann wie folgt beschrieben werden:

VLC Decodierungs-ROM-Tabellenkarte

VLC Codierungs-ROM-Tabellenmappe

1.2 Decodierung

Alle Tabellen für den Decodierer sind basierend auf Null- oder Einser-Zählungen umgeordnet. Wenn der MSB eines VLC Codes "0" ist, dann wird die Null-Zählung angewendet. Andererseits wird die Einser-Zählung benutzt. Z.B., wenn wir einen Code von "00001xxx" haben, dann haben wir 4 Nullen. Wenn wir "1110xxx" haben, dann haben wir eine 3 Einser-Zählung. Der Decodierungsablauf wird zuerst die Null/Eins- Zählung decodieren, wobei die Null/Eins-Zählung des VLC Codes an den ROM-Tabellenadressengenerator ausgegeben wird. Dann decodiert der Adressengenerator den Rest der Codes, um die Adresse zu erzeugen. Die Adresse beinhaltet zwei Teile: Einer ist der Offset; der andere, welcher die maskierte Adresse genannt wird, kann von der VLC-Tabelle hergeleitet werden. Die Adresse ist das logische ODER der zwei Teile. Die andere Information, die durch den Adressengenerator geliefert wird, kann wie folgt beschrieben werden:

- VLC Code-Größe.
- Spezielle Markierung: 2 Bit-Markierung sagt der Decodierungszustandsmaschine etwas über "ESCAPE (FLUCHT)", "END OF BLOCK (ENDE DES BLOCKES)", "STUFFING (AUFFÜLLEN)" oder "START CODE (STARTCODE)" von H.261 aus.
- Hoher Datenauszug ermöglicht: gültige Daten sind hohe 6 Bit.
- Vorzeichen/gerade ermöglichen: Diese Markierung zeigt an, daß die Decodierung das LSB des VLC als Vorzeichen oder gerades Bit basierend auf der Tabelle extrahieren sollte.
- Gültiges VLC.
- "Mask shift bits" und "mask": Diese zwei Signale werden angewendet, um die maskierten Adressen zu erzeugen.

Für die ROM-Tabelle werden an jeder Stelle Daten im hohen und tiefen Bitformat mit Ausnahme der Tabelle 14, 15 des MPEG-2 und der Tabelle 12/H.263 gespeichert. Die Größe der ROM-Tabelle für die Decodierung beträgt 332×12 Bits.

1.2.1 Tabelle 14/MPEG-2

Diese Tabelle ist dieselbe wie die Tabelle 2 - B.5c/MPEG-1 und die Tabelle 5/H.261.

Das ROM-Tabellenformat: BIT 10∼6: RUN (ABLAUF); BIT 5∼0: LEVEL (NIVEAU)

1.2.2 Tabelle 15/MPEG-2

Das meiste der Tabelle wird gemeinsam mit der Tabelle 14/MPEG-2 benutzt, da sie den gemeinsamen RUN-, LEVEL- und VLC-Code haben.

Das ROM-Tabellenformat: BIT 10∼6: RUN; BIT 5∼0: LEVEL.

1.2.3 Tabelle 12/H.263

Diese Tabelle hat einen weiteren Ausgangswert "LAST (ZULETZT)"' verglichen mit der Tabelle 14, 15 des MPEG-2.

Das ROM-Tabellenformat: BIT 11: LAST; BIT 10∼4: RUN, BIT 3∼0: LEVEL.

1.2.4 Bewegungscode/Makroblockzuwachs

Dieser Abschnitt deckt die Tabelle 1/MPEG-2, die Tabelle 10/MPEG-2, die Tabelle 2 - B.1/MPEG-1, die Tabelle 2 - B.4/MPEG-1, die Tabelle 1/H.261, die Tabelle 3/H.261 und die Tabelle 10/H.263 ab.

Anzumerken ist, daß für den Bewegungscode das LSB das Vorzeichenbit ist, mit Ausnahme von VLC = 1. Für den Makroblockzuwachs ist das LSB eine gerade Wertmarkierung, mit Ausnahme von VLC = 1. Deshalb decodieren wir nur die Hälfte der Tabelle. Die zwei Typen von Tabellen haben den gleichen VLC und den decodierten Wert, mit Ausnahme des hohen Teiles der Tabelle 10/H.263, wenn wir das Vorzeichen/gerade-Bit ignorieren. Der decodierte Wert beträgt bis zu 6 Bits, was bedeutet, daß wir zwei Datenwerte in eine Stelle setzen. Obwohl der decodierte Wert des niedrigeren Teiles der Tabelle 10/H.263 unterschiedlich zu den anderen ist, ist der Binärwert derselbe aufgrund des fixierten Punktes, d. h. wir benutzen 16 und eine halbe Stelle, um alle diese Tabellen abzudecken. Wir benutzen einen einfachen FSM, um die ROM-Adresse zu erzeugen.

In der Anwendung liefert, wenn der Bewegungscode decodiert worden ist, die ROM-Tabelle den absoluten Wert. Auf der anderen Seite, wenn der Adressengenerator das Vorzeichenbit freigibt, so wird der Decodierer das LSB als Vorzeichen extrahieren, in welchem Falle "1" negativ bedeutet und "0" positiv bedeutet. Der Algorithmus kann wie folgt beschrieben werden:
if (sign_enable == 1)
increment_value = sign + ROM_table_value;
else
increment_value = ROM_table_value;

Wenn die Makroblockadressen-Zuwachstabelle decodiert wird, leiten wir das Ergebnis aus dem ROM-Tabellenwert und der geraden Markierung her. Z.B. gibt die ROM-Tabelle uns einen Wert von "5". Wenn die gerade Markierung hoch ist, dann erhalten wird das Ergebnis von "10". Wenn die gerade Markierung niedrig ist, dann erhalten wir "11". Der Algorithmus kann wie folgt beschrieben werden:
if (even_enable = = 1)
increment_value = (ROM_table_value << 1)
| (∼ even_bit);
else
increment_value = ROM_table value:
ROM table format: BIT 11∼6; high data; BIT 5∼0; low data

1.2.5 Makroblockmuster

Dieser Abschnitt deckt die Tabelle 9/MPEG-2, die Tabelle 2 - B.3/MPEG-1 und die Tabelle 4/H.261(CBP) ab.

Der decodierte Wert beläuft sich auf bis zu 6 Bit, was bedeutet, daß wir zwei Daten in eine Stelle hinsetzen können, d. h. 32 Stellen werden benutzt, um all die Tabellen abzudecken.

ROM-Tabellenformat: BIT 11∼6: hohe Daten; BIT 5∼0: niedrige Daten.

1.2.6 Makroblocktyp

Dieser Abschnitt beschreibt die Tabelle 2, 3, 4/MPEG-2, die Tabelle 2 - B.2/MPEG-1, die Tabelle 2/H.261(MTYPE), und die Tabelle 3, 4/H.263(MCBPC).

Der decodierte Wert beläuft sich auf bis zu 5 Bits. Wir benutzen immer noch das Konzept der Hoch/Niedrig-Daten. Ein einfacher FSM wird benutzt, um die ROM-Adresse zu erzeugen.

ROM-Tabellenformat: BIT 11∼6: hohe Daten; BIT 5∼0: niedrige Daten.

Das Format des Makroblocktyps wird universell für jede Spezifikation definiert, welche auf dem MPEG basiert, obwohl einige Bits verschiedene Bedeutung für die verschiedenen Spezifikationen haben. Anzumerken ist, daß der H.263 2-Stufen-Decodierung benötigt, die auf seinem Informationserfordernis basiert, welches wie folgt beschrieben werden kann:
Decodiere MCBPC, welcher den 3 Bit-Makroblocktyp erhält.

Die Makroblocktyp-Nachschlagung beruht auf dem Makroblocktyp, der PB-Markierung und dem Bildtyp.

Die Formate des Makroblocktyps in der VLC-Tabelle können wie folgt beschrieben werden:

Makroblocktypformat von MPEG

MCBPC Format des H.263

Makroblocktypformat von H.261

Von der Tabelle 4 erhalten wir nicht nur den 3 Bit- Makroblocktyp, sondern auch das 2 Bit-Chroma-Muster. Der Makroblocktyp ist hier ein 3 Bit-Wert, welcher einen Bereich zwischen 0 bis 4 hat. Wie oben erwähnt, wird die detaillierte Makroblocktyp-Information in der zweiten Stufe decodiert werden. Die Decodierungstabelle kann wie folgt beschrieben werden:

Makroblock-Decodierungstabelle für H.263

1.2.7 DCT DC GRÖSSE

Dieser Abschnitt deckt die Tabelle 12, 13/MPEG-2 und die Tabelle 2 - B.5/MPEG-1 ab. Anzumerken ist, daß aufgrund der VLC Struktur die Einser-Zählung anstelle der Null-Zählung hier benutzt wird.

ROM-Tabellenformat: BIT 10∼6: hohe Daten: chroma; BIT 4∼0: niedrige Daten: luma. Bit 11 und Bit 4 sind reserviert.

1.2.8 CBPY

Dieser Abschnitt deckt die Tabelle 9/H.263 ab. Anzumerken ist, daß diese Tabelle zwei Sätze von Daten enthält, einer für das Inter-Bild und einer für das Intra-Bild. Ein Satz an Werten ist die Inversion des anderen Satzes, welches die Speicherung von einem Satz an Daten in dem ROM ermöglicht. Hier werden die Intra-Daten in den ROM gesetzt. Ein 4 Bit-Wert wird benutzt, um den CBPY-Wert zu beschreiben.

ROM-Tabellenformat: BIT 9∼6: hohe Daten; BIT 3∼0: niedrige Daten. Bit 11∼10 und Bit 5∼4 werden reserviert.

1.2.9 DUAL PRIME und MODUS

Dieser Abschnitt deckt die Tabelle 11/MPEG-2 und die Tabelle 7/H.263 ab.

Diese zwei Tabellen sind sehr einfach und klein, so daß sie direkt decodiert werden können.

1.3 Codierung

Ähnlich dem Decodierungsabschnitt benutzt der Codierungsablauf die Idee der Null/Einser-Zählung. Die ROM-Tabelle beinhaltet die Information der Null/Einser-Zählung, der Größe des Codes, die der ersten "1" auf Null- oder Einser-Zählung folgt, und des VLC-Codes, der der ersten/letzten "1" folgt. Entsprechend diesem Format kann die Größe der ROM-Tabelle auf 12 Bits pro Stelle mit 4 Ausnahmen in der Tabelle 12/H.263 begrenzt werden, welche durch spezielle Codierung gelöst werden. Das Format kann wie folgt beschrieben werden:

Allgemeines Format der Codierung

Format der Codierung der Tabelle 12/H.623

In den obigen Tabellen ist die VLC-Codierungsgröße die Größe des VLC-Codes, der der ersten/letzten "1" folgt. Der VLC-Code ist der VLC-Code, der der ersten/letzten "1" folgt. In dem Fall der Null-Zählung wird der VLC-Code, der der ersten "1" folgt, extrahiert. Andererseits sollte der VLC-Code aus den Bits extrahiert werden, die der letzten "1" folgen. Anzumerken ist, daß die Anwendung einer Einser- Zählung bei der Codierung unterschiedlich zu der der Decodierung ist. Die Einser-Zählung wird angewendet, wenn und nur wenn die Einser-Zählungsmarkierung durch den Adressengenerator freigegeben wird. Deshalb, wenn das MSB einer VLC 1 ist, jedoch die Einser-Zählungsmarkierung niedrig ist, dann wird der Null/Einser-Zählungsabschnitt der ROM-Tabelle 0 sein, was bedeutet, daß die Null- Zählung angewendet wird.

Die folgenden Beispiele decken alle möglichen Fälle der Codierung ab.

Beispiel 1

VLC = 0000011001, Einser Zählung_Freigabe = 0
Ergebnis für allgemeinen Fall: 0101 100 01001
Ergebnis für Tabelle 12/H.263 : 101 100 001001

Beispiel 2

VLC = 11001, Einser Zählung_Freigabe = 0
Ergebnis für allgemeinen Fall: 0000 100 01001
Ergebnis für Tabelle 12/H.263 : 000 100 001001

Beispiel 3

VLC = 11001, Einser Zählung_Freigabe = 1
Ergebnis für allgemeinen Fall: 0010 011 00001
Ergebnis für Tabelle 12/H.263

Die allgemeine Adresse wird durch Hinzufügen eines Offset und des Eingangswertes erzeugt.

1.3.1 Tabelle 14/MPEG-2

Diese Tabelle ist dieselbe wie die Tabelle 2 - B.5c/MPEG-1 und die Tabelle 5/H.261. Die Codierung bearbeitet Eingaben von RUN, FIRST DC, ESCAPE und END OF BLOCK.

Codierungsergebnis: Offset-Adresse, welche verwendet wird, um zu LEVEL oder RUN addiert zu werden, um die Adresse zu erzeugen.

1.3.2 Tabelle 15/MPEG-2

Das meiste der Tabelle wird gemeinsam mit der Tabelle 14/MPEG-2 benutzt, da sie denselben RUN, LEVEL und VLC-Code haben. Für einige spezielle Fälle wird eine Einser-Zählung angewendet. Die Codierung bearbeitet Eingaben von RUN, LEVEL, FIRST DC, ESCAPE und END OF BLOCK.

Codierungsergebnis: Offset-Adresse und Einser- Zählindikator.

1.3.3 Tabelle 12/H.263

Wie wir oben erwähnt haben, ist diese Tabelle sehr speziell. Wir benutzen das unterschiedliche Format, um mit ihr umzugehen. Leider haben wir einige Ausnahmen, bei welchen wir nicht 12 Bits benutzen können, um den VLC-Code zu beschreiben. Die Ausnahmen werden in Tabelle 9 beschrieben. Solche Ausnahmen können spezifisch codiert werden, ohne Benutzung der ROM-Tabelle.

Ausnahme der Codierung in Tabelle 12/H.263

Die Codierung bearbeitet Eingaben von RUN und ESCAPE.

Codierungsergebnis: Die Offset-Adresse, welche verwendet wird, um zu LEVEL oder RUN addiert zu werden, um die Adressen zu erzeugen.

1.3.4 Bewegungscode/Makroblockzuwachs

Dieser Abschnitt deckt die Tabelle 1/MPEG-2, die Tabelle 10/MPEG2, die Tabelle 2 - B.1/MPEG-1, die Tabelle 2 - B.4/MPEG-1, die Tabelle 1/H.261, die Tabelle 3/H.261 und die Tabelle 10/H.263 ab.

Wie in dem Decodierungsabschnitt erwähnt wird, können wir eine ROM-Tabelle und einen FSM für alle diese Tabellen gemeinsam nutzen. Der VLC-Code, der aus der ROM-Tabelle hergeleitet wird, sollte mit dem Vorzeichen/gerade Bit kombiniert werden, um den vollen VLC-Code herzustellen. Deshalb sind die Eingangswerte, die wir in diesem Codierungs-FSM bearbeiten, absolute Werte für den Bewegungscode, dessen LSB das Bruchbit ist, und der um ein Bit nach rechts verschobene Makroblockadressenzuwachs.

Die Codierung verarbeitet Eingaben von STUFFING und ESCAPE.

1.3.5 Makroblockmuster

Dieser Abschnitt deckt die Tabelle 9/MPEG-2 und die Tabelle 2 - B.3/MPEG-1 ab.

Die Adresse wird durch Hinzufügen von dem Offset und dem Musterwert gebildet.

1.3.6 Makroblocktyp

Dieser Abschnitt deckt die Tabelle 2, 3, 4/MEPG-2 und die Tabelle 2 - B.2/MPEG-1 ab.

1.3.7 TABELLE 3, 4/H.263 (MCBPC)

Die Information des Bildtyps, des Makroblocktyps und der Auffüll(STUFFING)-Markierung wird geliefert, um den ROM- Tabellenadressen-Offset zu erzeugen. Die Adresse ist die Summe der Offset-Adresse- und des CBPC.

1.3.8 TABELLE 2/H.261 (MTYPE)

Der Adressengenerator ist sehr kompliziert. Wir gehen davon aus, daß er korrekt arbeitet.

1.3.9 CBPY

Wie wir in dem Decodierungsabschnitt diskutiert haben, codieren wir einfach die Intra-Bilddaten. Wenn der Bildtyp ein Inter-Bild ist, so sollten die Daten zuerst invertiert werden.

Die Adresse ist die Hinzufügung des Offsets und des CBPY- Wertes.

1.3.10 DCT DC SIZE (GRÖSSE)

Dieser Abschnitt deckt die Tabelle 12, 13/MPEG-2 und die Tabelle 2 - B.5/MPEG-1 ab.

Da einige VLC-Codes von Luma und Chroma dieselben sind, nutzen wir einige ROM-Tabellen von ihnen gemeinsam. Die Chroma-Markierung und einige Bits an dem Wert werden benutzt, um die Offset-Adresse zu erzeugen. Wir können die ROM-Adresse durch Hinzufügen des Offsets zu dem tatsächlichen Wert erhalten.

1.3.11 DUAL PRIME und MODB

Dieser Abschnitt deckt die Tabelle 11/MPEG-2 und die Tabelle 7/H.263 ab.

Diese zwei Tabellen sind sehr einfache und kleine Tabellen, so daß wir sie direkt codieren können.

2.0 Hardware-Beschreibung

Die Hardware der VLC-Codierung/Decodierung ist in dem Block von "VLC" beinhaltet. Dieser Block enthält drei Unterblöcke. Diese Blöcke werden verwendet, um die ROM-Tabellenadresse oder die Decodierungs/Codierungsdaten selbst zu erzeugen. "VLC_DEC" wird benutzt, um den VLC zu decodieren und die ROM-Tabellenadresse zu erzeugen. "VLC ENC" ist ein Block, um die VLC zu codieren, welche entweder die ROM-Tabellenadresse oder die spezielle Codierung für die TCOEF- Tabelle von H.263 erzeugt. "LOOKUP (NACHSCHLAGEN)" gibt die VLC-Daten aus, die auf entweder dem ROM-Tabellenwert oder dem speziellen codierten Wert basieren.

2.1 VLC-Decodierungsadressengenerator

Der Kern des VLC_DEC ist das Decodierungs-FSM. Dieses FSM decodiert die Eingangsinformation und steuert die Adressenerzeugung. Die Eingänge und die Definition des FSM können wie folgt beschrieben werden:

- NULL/EINSER-Zählung (15 bits): liefert Null/Einser- Zählwerte.
- NULL/EINSER-Zählung (4 Bits): liefert Null/Einser- Zählwerte. Der Zweck des Verwendung von zwei verschiedenen Bitzählungssignalen ist es, die Eingangsdaten dünn zu machen, welches die Gate-Kunden reduziert. In den meisten der Fällen wird das 15 Bit- Signal benutzt.
- EINSER-Zählung ermöglichen (1-bit): Einser- Zählindikator.
- Tabellentyp (6 Bits): Tabellentyp
VLC_DEC FSM Tabellentypformat

VLC_DEC FSM Tabellentypformat

Modus (9 Bit): Betriebsmodus

VLC_DEC FSM Modusformat

Die Definition der Spezifikation und des Bildtyps werden in den Pin-Definitionen erklärt.

Ein spezieller Algorithmus wird benutzt, um die Decodierungs- ROM-Tabellenadresse zu erzeugen, um die Hardware zu vereinfachen und die ROM-Zugriffszeit zu sichern. Die Herstellung ist wie folgt:
Schritt 1: Erzeugen der Offset-Adresse (OFFSET).
Schritt 2: Erzeugen des 4 Bit-Verschiebungsbetrages (MASK_SHFT) und der rechten Verschiebungs- 16 Bit-FIFO_DATEN mit diesem Betrag. Dann extrahieren der 4 am wenigstens signifikanten Bits (FOL_DATEN).
Schritt 3: Bits kehren die 4 Bits um, die in dem Schritt 2 erhalten werden.
Schritt 4: Erzeugen eines 4 Bit-Maskierungssignales, um die Daten zu maskieren, die in Schritt 3 erhalten werden (MASK).
Schritt 5: logische ODER-Operation bezgl. dem Ergebnis von Schritt 4 mit der Offset-Adresse. Das Ergebnis ist die ROM-Tabellenadresse.

Kombinieren dieser Schrittresultate:
Adresse = OFFSET | (BITUMKEHRUNG (Bit(3∼0) von (FIFO_DATEN << MASKIERUNGS_SHFT)) & MASKIEREN)

Der Ausgang des FSM ist wie unten:

- MASK (4 Bits): Maskierungsdaten
- OFFSET (9 Bits): ROM Tabellen-Offset-Adresse
- MASK_SHFT (4 Bits): Verschiebungsbetrag
- SIZE (5 Bits): VLC Größe
- SPECIAL_FLAG (3 Bits): Extra-Information für Decodierung:

Definition der speziellen Markierung (Flag) der VLC_DEC

- VALID_VLC (1-Bit): Gültige VLC-Codemarkierung
- HIGH_DATA_INDICATOR (1 Bit): Extrahiert hohe 6 Bit von den ROM-Daten

Eingangspins:

- FOL_DATA (4 Bits): verschobene FIFO_DATEN (siehe Schritt 2 oben)
- CNT (4 Bits): Null/Einser-Zählung
- ONE_CNT_EN (1 Bit): Einser-Zählindikator
- MODE (14 Bits): Tabellentyp und andere Informationen.

Die Definition ist wie folgt:

Format von MODE in VLC_DEC

SPEZIFIKATION: 00 = MPEG-1; 01 = MPEG-2; 10 = H.261, 11 = H.263;
BILDTYP: 00 = RESERVIERT; 01 = INTRA; 10 = VORHERGESAGT; 11 = ZWEIGERICHTET;

- FIFO_DATEN (16 Bits): Daten beinhalten VLC Ausgangspins:
- ROM_ADR (10 Bits): ROM-Tabellenadresse
- MASK_SHFT (4 Bits): Verschiebungs-Betrag für FIFO_DATEN (siehe Schritt 2 oben)
- SIZE (5-Bits): VLC-Größe
- SPECIAL_O (3 Bits): Spezialmarkierung (siehe FSM- Ausgang)
- VALID_VLC (1 Bit): Gültige VLC-Markierung
- HIGH_DATA (1 Bit): Indikator des Extrahierens des LSB von der VLC als Vorzeichen von der geraden Markierung
- FULL_DATA (1 Bit): Volle 12 Bit-Datenstruktur, welche hoch ist, wenn der DCT-Koeffizient decodiert wird
- TABELLE (6 Bits): in dem FSM Eingang definiert
- T_MODE (9 Bits): in dem FSM Eingang als MODE definiert

2.2 VLC_ENC

Wie in dem VLC-Codierungskernabschnitt codiert das VLC_ENC den Code mit veränderbarer Länge. Der Ausgang dieses Abschnittes ist entweder eine ROM-Tabellenadresse oder eine spezielle Codierung des VLC. Wie in dem Abschnitt 1.0 beschrieben wird, folgt die Codierungsdatenstruktur dem 12 Bit-Datenformat, mit Ausnahme bestimmter spezieller Fälle von TCOEF für H.263. Vom Standpunkt der Hardware ist es wesentlich einfacher als der VLC_DEC-Abschnitt, obwohl ein 10 Bit-Addierer benutzt wird, um die ROM-Tabellenadresse zu erzeugen.

Ähnlich dem VLC_DEC ist der Kern dieses Abschnittes ein FSM, der VLC_ENC genannt wird. Ein anderes FSM, ENC_SP wird für die spezielle Codierung benutzt.

Die Eingangssignale an das FSM VLC_ENC sind dieselben, wie die Einganspins von diesem Abschnitt:

- LAST (1 Bit): Wert von LAST für die Tabelle des TCOEF von H.263.
- RUN/VALUE (6 Bits): Wenn die DCT-Koeffiziententabelle codiert wird, bedeutet dieser Eingang RUN: Andernfalls ist er ein allgemeiner Wert, z. B. PATTERN.
- LEVEL (6 Bits): DCT Koeffizienten LEVEL.
- SPECIAL_FLAG (2 Bits): Spezialmarkierung, welche in dem VLC_DEC Abschnitt definiert wird.
- TABELLE (6 Bits): gleich wie bei VLC_DEC.
- MODE (9 Bits): gleich wie bei VLC_DEC.

Die ROM-Adressenerzeugung ist sehr problemlos. Der FSM liefert eine Offset-Adresse, welche zu VALUE (RUN) oder LEVEL oder 0 hinzuaddiert wird, um die Adresse zu bilden. Für die spezielle Codierung ist, da solche VLCs dieselben Größen und Null-Zählungen haben, der Ausgang die 2 am wenigstens signifikanten Bits, die in den Code rekonstruiert werden.

Die Ausgangspins können wie folgt beschrieben werden:

- ONE_CNT_FLG (1 Bit): meldet, daß der VLC Konstruktionsabschnitt "1"-Zählung benutzt.
- SIGN_EN_BIT: meldet, daß der VLC Konstruktionsabschnitt das Vorzeichen/gerade Bit als VLC LSB setzt.
- SPECIAL_ENCODE (1 Bit): spezielle Codierungsmarkierung.
- VLC (2 Bits): spezielle codierte VLC Code LSBs.
- ADR_A (16 Bits): Offset-Adresse. Anzumerken ist, daß die hohen 6 Bits 0 sind.
- ADR_B (16 Bits): ein anderer Teil der Adresse. Anzumerken ist, daß die hohen 10 Bits immer 0 sind.

2.3 Nachschlagen (LOOKUP)

Dieser Abschnitt liefert die Codierungs/Decodierungs-VLC- Daten. Dieser Block handhabt die folgenden Situationen:

- regulärer 12 Bit-Codierungs/Decodierungs-ROM- Tabellenwertausgang
- den Ausgang der Bit hoch/niedrig Decodierungsdaten
- Rekonstruktion spezieller Codierungsdaten

Wenn erforderlich, werden die Ausgangsdaten mit Nullen aufgefüllt.

Eingangspins

- D_ADR (10 Bits): Decodierungs-ROM-Adresse
- E_ADR (10 Bits): Codierungs-ROM-Adresse
- ENCODE (1 Bit): 1: Codieren; 0: Decodieren
- HIGH (1 Bit): Extrahiert die Markierung mit hohen 6 Bit
- ENABLE (1 Bit): Datenmarkierung mit vollen 12 Bit
- VLC (2 Bits): spezieller Codierungscode
- SPECIAL_ENCODE (1 Bit) : Markierung für spezielle Codierung

Ausgangspins

LOOKUP (l6 Bits): VLC-Code

Claims

1. Eine Vorrichtung zum Codieren oder Decodieren von Videodaten, wobei die Vorrichtung aufweist:
einen Vektorprozessor (220) zum Ausführen einer linearen Transformation an Videodaten,
einen Bitstrom-Prozessor (245) zum Komprimieren eines Ausgangssignals des Vektorprozessors (220) oder zum Dekomprimieren von Videodaten als Eingangssignal an den Vektorprozessor und
eine Steuerschaltung (210) zum Synchronisieren des Betriebs des Vektorprozessors (220) und des Bitstrom- Prozessors (245),
wobei der Bitstrom-Prozessor (245) durch die Steuerschaltung (210) unterbrochen werden kann, um eine Verarbeitung eines Stroms von Videodaten anzuhalten und um die Verarbeitung eines anderen Stroms von Videodaten zu starten, so daß der Bitstrom-Prozessor beide Ströme von Videodaten annähernd gleichzeitig verarbeiten kann, damit es der Vorrichtung ermöglicht wird zwei Ströme von Videodaten in Echtzeit zu Codieren oder Decodieren.

2. Vorrichtung nach Anspruch 1, bei der jeder Strom von Videodaten ein Bewegtbild darstellt.

3. Eine Vorrichtung zum Codieren oder Decodieren von Videodaten, wobei die Vorrichtung aufweist:
einen Vektorprozessor (220) zum Ausführen einer linearen Transformation an Videodaten und
einen Bitstrom-Prozessor (245) zum Komprimieren eines Ausgangssignals des Vektorprozessors (220) oder zum Dekomprimieren von Videodaten als Eingangssignal an den Vektorprozessor,
wobei der Vektorprozessor (220) so programmiert werden kann, daß er einen einzelnen arithmetischen oder boolschen Befehl ausführt, und wobei der Bitstrom-Prozessor (245) nicht so programmiert werden kann, daß er einen einzelnen arithmetischen oder boolschen Befehl ausführt.

4. Ein Verfahren zum Codieren oder Decodieren von Videodaten, wobei das Verfahren aufweist:
einen Vektorprozessor (220), der eine lineare Transformation an Videodaten ausführt,
einen Bitstrom-Prozessor (245), der ein Ausgangssignal des Vektorprozessors (220) komprimiert oder der Videodaten zur Eingabe an den Vektorprozessor dekomprimiert, und
eine Steuerschaltung (210), die den Betrieb des Vektorprozessors (220) und des Bitstrom-Prozessors (245) synchronisiert,
wobei der Bitstrom-Prozessor durch die Steuerschaltung (210) unterbrochen wird, um das Verarbeiten eines Stroms von Videodaten anzuhalten und um die Verarbeitung eines anderen Stroms von Videodaten zu starten, so daß der Bitstrom-Prozessor beide Ströme von Videodaten gleichzeitig verarbeitet, um es der Vorrichtung zu ermöglichen, zwei Ströme von Videodaten in Echtzeit zu codieren oder decodieren.

5. Verfahren nach Anspruch 4, bei dem jeder Strom von Videodaten ein Bewegtbild darstellt.

6. Ein Verfahren zum Codieren oder Decodieren von Videodaten, wobei das Verfahren aufweist:
einen Vektorprozessor (220), der eine lineare Transformation an Videodaten ausführt, und
einen Bitstrom-Prozessor (245), der eine Ausgabe des Vektorprozessors komprimiert oder der Videodaten zur Eingabe an den Vektorprozessor dekomprimiert,
wobei der Vektorprozessor (220) so programmiert werden kann, daß er einen einzelnen arithmetischen oder boolschen Befehl ausführt, und wobei der Bitstrom-Prozessor (245) nicht so programmiert werden kann, daß er einen einzelnen arithmetischen oder boolschen Befehl ausführt.