Sie sind auf Seite 1von 103

Serkan Kalyoncu Matrikelnummer: 147801

Diplomarbeit
Thema:
Modellierung eines echtzeitrelevanten Steuerungskonzepts fr komplexen ASIC zur Video-Formatkonvertierung

Betreuer:
H. U. Post H. Liebig

Stand der Technik

Inhaltsverzeichnis
Inhaltsverzeichnis.........................................................................................................i 1 Zusammenfassung.....................................................................................................1 2 Die Notwendigkeit der Formatkonversion und des HiCon Formatkonverters.......2 3 Grundzge der Formatkonversion............................................................................3 3.1 nderung der Bildwiederholfrequenz.........................................................................................4 3.2 nderung der Bildauflsung.......................................................................................................5 3.3 nderung der Bildkodierung......................................................................................................6 4 Formatkonversion mit dem HiCon ASIC...................................................................9 4.1 Bewegungsschtzung................................................................................................................10 4.2 Die Filterung.............................................................................................................................12 4.2.1 Die Zwischenbildfilterung.................................................................................................12 4.2.2 Die Zwischenzeilenfilterung..............................................................................................14 5 Der Aufbau des ASIC...............................................................................................16 5.1 Frontend Einheit.......................................................................................................................18 5.2 Bewegungsschtzer..................................................................................................................18 5.3 Zeilenfiltereinheit.....................................................................................................................19 5.4 Zwischenbildfilter....................................................................................................................20 5.5 Ausgabeeinheit..........................................................................................................................21 5.6 Audioverzgerungseinheit........................................................................................................21 5.7 Parametereinheit.......................................................................................................................22

Anhang A: Handbuch fr den Simulator 5.8 Parameterbus............................................................................................................................22 5.9 Datenspeicher (Bildspeicher)...................................................................................................23 5.10 Datenbus................................................................................................................................25 5.11 Einheitenzwischenspeicher....................................................................................................25 6 Theoretische Betrachtung zu den Aufgaben der Systemkontrolle.......................27 6.1 Die Generierung der Ausgabesequenz.....................................................................................27 6.1.1 Das Wandlungsverhltnis..................................................................................................27 6.1.2 Die visuelle Notation..........................................................................................................27 6.1.3 Der Bindungsbereich der Sttzbilder und die Positionen zur Bildgenerierung................28 6.1.4 Ausnahmebehandlung bei Movie Mode........................................................................31 7 Spezifikation der Systemkontrolle..........................................................................32 7.1 Generelle Betrachtungen..........................................................................................................32 7.2 Operationen fr beide Modi.....................................................................................................33 7.2.1 Algorithmus fr die Berechnung der bentigten Zwischenbilder.....................................33 7.2.2 Speicherverwaltung in der Systemkontrolle......................................................................33 7.2.3 Lesen der Eingangsbilder...................................................................................................34 7.2.4 Erzeugen der Blockvektoren..............................................................................................34 7.3 Vom Modus abhngige Operationen........................................................................................35 7.3.1 Finden von konsistenten Operationszyklen.......................................................................35 7.3.2 Interlaced Modus Operationen...........................................................................................35 7.3.2.1 Deinterlacing der halbbildkodierten Eingangsbilder..................................................35 7.3.2.2 Zwischenbildgenerierung fr Luminanzdaten............................................................36 7.3.2.3 Zwischenbildgenerierung fr Chrominanzdaten........................................................37 7.3.2.4 Bildausgabe.................................................................................................................38 7.3.3 Progressiv Modus Operationen..........................................................................................38 7.3.3.1 Zwischenbildgenerierung fr Luminanzdaten............................................................38 7.3.3.2 Zwischenbildgenerierung fr Chrominanzdaten........................................................39

ii

Stand der Technik 7.3.3.3 Bildausgabe.................................................................................................................39 8 Stand der Technik....................................................................................................41 8.1 Die Entwicklung der Systemkontrolle in HDL.........................................................................41 8.1.1 Die Komplexitt des Steuermechanismus.........................................................................41 8.1.2 Die bentigte Chipflche...................................................................................................41 8.1.3 Sptere Austauschbarkeit und Freiraum fr Verbesserungen...........................................42 8.2 Die Systemkontrolle als Programm fr eingebettete Prozessoren..........................................42 8.2.1 Nachteile der Software-Lsung.........................................................................................43 8.2.1.1 Abarbeitungsgeschwindigkeit.....................................................................................43 8.2.1.2 Anstieg der Leistungsaufnahme des ASICs...............................................................43 8.2.1.3 Zunahme der externen Komponenten.........................................................................43 8.2.2 Vorteile der Software-Lsung............................................................................................44 8.2.2.1 Krzere Entwicklungszeiten.......................................................................................44 8.2.2.2 Einsparungen bei der Chipflche................................................................................44 8.2.2.3 Austauschbarkeit und Verbesserbarkeit der Systemsteuerung..................................44 8.2.2.4 Benutzerspezifische Varianten...................................................................................44 8.3 Die Klassifizierung der Plattform zur Systemsteuerung..........................................................44 8.4 Die Wahl der Programmiersprache fr die Implementierung.................................................45 8.5 Verifizierungsstrategien............................................................................................................46 8.6 Zusammenfassende Klassifizierung..........................................................................................48 9 Implementierung......................................................................................................49 9.1 berlegungen bezglich Speicherausnutzung sowie Performanz des Programms.................49 9.1.1 Bibliothekenbenutzung......................................................................................................49 9.1.2 Benutzung von Threads.....................................................................................................49 9.1.3 Dynamische Speicherverwaltung......................................................................................50 9.2 Implementierungsstrategien.....................................................................................................51

iii

Anhang A: Handbuch fr den Simulator 9.2.1 Das Konzept der quasiparallel arbeitenden Zustandsmaschinen als Substitut fr Threads .....................................................................................................................................................51 9.2.2 Systemtiming......................................................................................................................55 9.2.2.1 Vollbildmodus.............................................................................................................56 9.2.2.2 Halbbildmodus............................................................................................................57 9.2.3 Partitionierung des HiCon Datenspeichers........................................................................60 9.2.4 Abbildung des HiCon Datenspeichers ..............................................................................61 9.2.5 Operationen auf Erweiterungsregister...............................................................................64 9.2.6 Unterbrechungsroutinen.....................................................................................................65 9.2.7 Startkode.............................................................................................................................65 9.2.8 Zeitliches Verhalten der Komponenten ausnutzen............................................................66 9.2.9 Verhalten beim Einschwingen...........................................................................................67 9.2.10 Verhalten bei Szenenwechsel..........................................................................................68 9.2.11 Movie Mode Behandlung................................................................................................68 9.3 Implementierung des Simulators..............................................................................................71 9.3.1 Die Architektur des Simulators..........................................................................................71 9.3.2 Einbettung der Systemsteuerung in den Simulator...........................................................72 10 Optimierung............................................................................................................74 10.1 Generelle Optimierungsstrategien.........................................................................................74 10.1.1 Zeigerarithmetik...............................................................................................................74 10.1.2 Zeitkritische Funktionen in Assembler............................................................................74 10.1.3 Integerarithmetik vs. Fliekommaarithmetik..................................................................74 10.2 Optimierung des Vollbildmodus.............................................................................................75 10.2.1 Optimierungskonzept.......................................................................................................75 10.2.2 Optimieren hinsichtlich des Systemtimings....................................................................75 10.2.3 Zentralisieren des Algorithmus und das Vorerfassen der Wandlungsschritte................76 10.2.4 Paketrotation.....................................................................................................................79 10.2.5 Speicherfreigabe...............................................................................................................80 11 Verifizierung...........................................................................................................82

iv

Stand der Technik 11.1 Verifizierung mit dem Simulator.............................................................................................82 11.2 Verifizierung mit dem HiCon Ersatzmodell...........................................................................82 11.3 Weitere Verifizierungsarbeiten in der Zukunft.......................................................................83 12 Bewertung der Arbeit und weitere Ausblicke.......................................................84 13 Abbildungsverzeichnis..........................................................................................86 14 Tabellenverzeichnis...............................................................................................90 15 Literaturverzeichnis...............................................................................................92 Anhang A: Handbuch fr den Simulator..................................................................94 Grundkonzept des Simulators........................................................................................................94 Die Bedienung des Simulators.......................................................................................................94 1) Abbild des Datenspeichers:....................................................................................................94 2) Status der Einheiten:...............................................................................................................95 3) Programminterner Zustand:....................................................................................................95 4) Die Kontrollelemente:.............................................................................................................95 5) Ausgabe der Systemkontrolle:................................................................................................96 6) Zustande der Kontrollzustandmaschinen:..............................................................................96

Stand der Technik

1 Zusammenfassung
Zur Zeit befindet sich beim Heinrich-Hertz-Institut fr Nachrichtentechnik der ASIC HiCon in Entwicklung, der fr die Formatkonvertierung digitaler Videodaten ausgelegt ist. Hierbei ist ein komplexes Konzept zur Steuerung der Systemkomponenten erforderlich, welches im Rahmen dieser Arbeit entworfen und implementiert wird. Nach der Darstellung der allgemeinen und fr dem ASIC spezifischen Formatkonvertierungsstrategien werden die einzelnen Komponenten des ASICs vorgestellt. Im Kapitel 6 folgt eine theoretische Betrachtung der Aufgaben der Systemkontrolle. Auf die Spezifikation der Systemkontrolle wird im Kapitel 7 eingegangen. Danach werden mgliche Alternativen hinsichtlich der Realisierung errtert. Die nachfolgenden drei Kapitel behandeln die Implementierung, Optimierung sowie Verifizierung der Systemkontrolle. Anschlieend werden die gewonnenen Ergebnisse diskutiert, und es wird ein Ausblick auf zuknftige Verbesserungen vorgestellt. Im Anhang befindet sich eine Bedienungsanleitung fr den Simulator, der speziell fr die Verifizierung der Systemkontrolle entwickelt wurde.

Anhang A: Handbuch fr den Simulator

2 Die Notwendigkeit der Formatkonversion und des HiCon Formatkonverters


Der Begriff Multimedia steht fr die Verschmelzung und Zusammenarbeit verschiedener Gerte zur audiovisuellen Nutzung. Dadurch knnen unter anderem Gerte der Unterhaltungs-, Kommunikations- und Computerindustrie miteinander verschaltet werden. Dieses Zusammenarbeiten wird durch den Austausch von Audio- sowie Videodateien gewhrleistet. Jedoch haben die Gerte nichtnormierte Eigenschaften sowie Leistungsdaten. Ferner gibt es die verschiedensten Standards zur Kodierung der Daten. Um Daten zwischen zwei unvertrglichen Gerten auszutauschen, mssen die Daten des Ausgabegertes in eine fr das Eingabegert normierte Form gebracht werden. Die Formatkonvertierung ist aus dieser Notwendigkeit entstanden. Heute sind die an die Formatkonvertierung gestellten Ansprche jedoch gestiegen: Die Formatkonvertierung soll nicht nur die Daten in eine fr den Klienten bearbeitbare Form bringen, sondern die Daten auf die Vorzge des Klienten anpassen, in dem sie die in den Daten enthaltene Information anreichern. So soll ein hochauflsender Monitor niedrigauflsende Bildsequenzen in der gewohnt hochauflsenden Qualitt und mit feineren Bewegungsstufen zeigen. Die Konvertierungsmethoden bei der Videoformatkonvertierung, die diese Art von Wandlung bewltigen knnen, mssen neben Filteroperationen auch die Bewegung der Objekte verfolgen, um passende Zwischenbilder sinnvoll generieren zu knnen. Als eine Anwendung, die markttauglich ist, ist die Wandlung der Fernseh- und Videosignale fr moderne Fernsehgerte zu nennen. Die Konsumenten wollen die Kapazitten ihrer Gerte voll ausschpfen. So knnen z.B. die in 50Hz Halbbildverfahren ausgestrahlten Fernsehsignale in 100Hz Vollbildsignale umgewandelt werden. Eine hochqualitative Wandlung fgt neue Bilder zwischen vorhandene Bilder, die im Ausgangsmaterial nicht vorhanden sind. Gerade bei dieser Anwendung muss die Konvertierung in Echtzeit erfolgen. Diese Aufgabe kann nur von einem ASIC bewerkstelligt werden, da Software hierfr auf herkmmlichen Prozessoren zur Zeit zu langsam ist. HiCon wird als ein ASIC konzipiert, der diese Aufgaben zur besten Zufriedenheit erfllen kann. 2

Stand der Technik

3 Grundzge der Formatkonversion


Formatkonvertierung hat die Aufgabe, eine Sequenz oder einem Strom von Bildern in eine andere Sequenz bzw. Strom zu konvertieren. Wegen Ihrer Endlichkeit wird im weiteren Ablauf dieser Betrachtung von Bildsequenzen oder kurz Sequenzen geredet. Strme von Bildern knnen als unendliche Sequenzen betrachtet werden. Somit ist die Formatkonvertierung eine Abbildung, welche eine Sequenz S in eine Sequenz S berfhrt. S kann eine oder mehrere der folgenden Merkmale aufweisen: 1. Die Bildwiederholfrequenzen von S und S sind unterschiedlich. Daher beinhaltet S eine andere Anzahl von Bilder als S. 2. Die Auflsung der einzelnen Bilder in Bildpunkten ist bei S und S verschieden. 3. Die Kodierung der einzelnen Bilder von S und S ist verschieden. An dieser Stelle werden nun fr die drei oben genannten Punkte anhand von Beispielen elementare Methoden zur Formatkonvertierung aufgefhrt. Diese Methoden werden, obwohl sie nicht den Stand der Technik darstellen, von einigen Systemen angewendet. Letzten Endes bilden diese Methoden aber den Grundstein der Formatkonvertierung. Ferner sind sie zum Verstndnis und zur Beurteilung von fortgeschrittenen Methoden, die in spteren Abschnitten vorgestellt werden, sehr ntzlich.

Zeit

Bild 1

Bild 2

Bild 3

Abbildung 1: Die

Anfangssequenz.

Anhang A: Handbuch fr den Simulator Um eine Formatkonvertierung durchzufhren, ist eine Sequenz notwendig. Im folgenden soll auf der Sequenz von Abbildung 1 operiert werden. Sie besteht aus drei Einzelbildern und stellt ein sich bewegendes Pendel dar.

3.1 nderung der Bildwiederholfrequenz


Eine Erhhung der Bildwiederholfrequenz wird durch das Kopieren von schon vorhandenen Bildern ermglicht. Wird die Bildwiderholungsfrequenz verringert, werden Bilder ausgelassen. Um die Beispielsequenz auf die doppelte Frequenz zu konvertieren, werden die Bilder doppelt ausgegeben (siehe Abbildung 2).

Z B i ld 1 B

e i t i l d 2 B i l d 3

i l d

i l d

i l d

i ld

i ld

i l d

Abbildung 2: Frequenzverdoppelung durch Bildkopierung.

Die Frequenzverdopplung hat die ursprngliche Sequenz nicht bereichert. Daher kann ein Betrachter keinen subjektiven Unterschied zur Ausgangsequenz bemerken, obwohl in der selben Zeit die doppelte Anzahl von Bildern gezeigt wurde. Bei Frequenzerhhungen, die kein ganzzahliges Vielfaches der Ausgangsfrequenz beinhalten, treten jedoch bei diesem Verfahren Verflschungen hinsichtlich der Bewegung im Bild auf. Diese Verflschungen machen sich oftmals als Unstetigkeiten 4

Stand der Technik bei der Bewegung bemerkbar. Als nchstes wird die Bildwiederholungsfrequenz der Anfangssequenz um den Faktor 1.5 erhht (siehe Abbildung 3), um den oben geschilderten Effekt zu demonstrieren.

Z B i l d 1 B

e i t i l d 2 B i l d 3

i l d

i l d

i l d

i l d

Abbildung 3: Schwchen bei der Bildkopierung.

Um die Frequenzerhhung um den Faktor 1.5 durchzufhren, wird jeweils ein Bild der Anfangsequenz bernommen und das nachfolgende Bild wird doppelt bernommen. Der Betrachter stellt nun fest, dass das Pendel zur Mittelstellung zugehend langsamer wird, um dann aus der Mittelstellung heraus zu beschleunigen. Hierdurch wird die Bewegungsinformation der Sequenz verflscht. Diese Beobachtungen gelten auch fr Frequenzverringerungen.

3.2 nderung der Bildauflsung


Punkt 2 wird durch die Skalierung der Ausgangsbilder erreicht. Bei der Skalierung werden die Bildpunkte der Ausgangsbilder vervielfacht bzw. verringert. Hierbei wird die Skalierung in X- und Y-Richtung separat ausgefhrt, so dass verschiedene Skalierungsfaktoren in X- und Y-Richtung angelegt werden knnen. Die Methode gleicht

Anhang A: Handbuch fr den Simulator dem Ansatz aus Punkt 1. Bei der Abbildung 4 wird das Ursprungsbild in X-Richtung um den Faktor 2 und in Y-Richtung um den Faktor 1.5 skaliert.

r i g in S

a l k a l i e r t X = 2 , Y = 1 . 5

Abbildung 4: Das Skalieren durch Bildpunktvervielfachung ohne Kantenglttung.

In X-Richtung wird jeder Bildpunkt verdoppelt. In Y-Richtung hingegen wird nur jeder zweite Bildpunkt verdoppelt.

3.3 nderung der Bildkodierung


Punkt 3 wird unter anderem hufig dazu eingesetzt, um die bei der Fernsehtechnik blichen Halbzeilenbilder in progressive Bilder umzuwandeln. Diese Prozedur wird als Deinterlacing bezeichnet. Abbildung 5 zeigt die Sequenz mit dem Pendel aus der vorangehenden Betrachtung in Halbbildern in einem 16x8 Bildpunktraster. Top bezeichnet ein Halbzeilenbild mit nur geraden Zeilen des Originals. Bottom dagegen beinhaltet die ungeraden Zeilen des Originalbildes.

T o

o t t o

T o

Z e
Abbildung 5: Ausgangssequenz halbzeilenkodiert.

it

Stand der Technik

Im Idealfall sollte die Sequenz nach dem Deinterlacing wie in Abbildung 6 aussehen. Letzten Endes stellt diese Sequenz die Ausgangssequenz dar, die in die Sequenz von Abbildung 5 durch Halbzeilenbildkodierung berfhrt wird.

Abbildung 6: Originalsequenz in einem groben Bildpunktraster dargestellt.

Die mit dem geringsten algorithmischen Aufwand verbundene Methode zum Deinterlacing ist die Zeilenverdoppelung. Sie entspricht dem Skalieren des Bildes um den Faktor 2 in Y-Richtung und kann deshalb von einer eventuell vorhandenen Skalierungseinheit durchgefhrt werden. Es fhrt jedoch, wie in Abbildung 7 ersichtlich, zu keiner Detailzunahme. Bei einer Gegenberstellung dieses Ergebnis mit dem Sollzustand von Abbildung 6 entstehen starke Stufungen an nicht orthogonalen Kanten. In Bildbereichen mit hohen Ortsfrequenzen entstehen durch die unzulssigerweise verringerte vertikale Bildinformation Aliasfehler und Schrfeverlust.

Abbildung 7: Deinterlacing durch Zeilenverdoppelung.

Anhang A: Handbuch fr den Simulator

Eine weitere Methode zur Progressivwandlung ist die Halbbildverschachtelung. Hierbei werden die fehlenden Zeilen fr ein Bild N durch die Zeilen des Bildes N+1 ersetzt. Fr ein Beispiel dieses Verfahrens siehe Abbildung 8.

Abbildung 8: Deinterlacing durch Bildverschachtelung.

Die Zwischenbildverschachtelung fhrt zur Vermischung von zeitlich unterschiedlichen Bildern. Die entstehenden Bilder zeigen eine deutliche Verfransung sowie Unschrfe auf. Bei schnellen Bewegungen werden diese Seiteneffekte verstrkt. Kleinere Objekte, wie z.B. kleine Textzeilen knnen hierbei, abhngig von der Bewegungsgeschwindigkeit, unlesbar werden.

Stand der Technik

4 Formatkonversion mit dem HiCon ASIC


Der HiCon Videoformatkonverter arbeitet mit einem Verfahren, das als bewegungskompensierte Wandlung bezeichnet wird. Die bewegungskompensierte Wandlung basiert auf der Idee, die Bewegung im Bild zu erkennen und fr die Interpolation knstliche Bilder sowie das Deinterlacing einzusetzen. Um die Bewegung in einem bestimmten Bild festzustellen, vergleicht der Konverter das Bild bei einer Vorwrtsschtzung mit seinem Nachfolgerbildern bzw. bei einer Rckwrtsschtzung mit seinem Vorgngerbildern. Der fr den Vergleich der Bilder zustndige Teil des Formatkonverters, wird im allgemeinen Bewegungsschtzer genannt. Der Bewegungsschtzer liefert fr jeden Bildpunkt des untersuchten Bildes einen Vektor, der die Bewegung dieses Bildpunktes angibt. Anhand dieser Information knnen die Zwischenzeilen- und Zwischenbildfilter des Wandlers die Formatkonvertierung durchfhren. Dabei wird der besagte Vektor fr die Bestimmung der zur Filterung in Frage kommenden Bildpunkte des Vorgnger- und Nachfolgerbildes benutzt. Beim Zwischenzeilenfilter handelt es sich um eine Komponente, der fr die Halbbild/Progressiv Wandlung (Deinterlacing) zustndig ist. Zwischenbildfilter hingegen sind in der Lage, vllig neue Bilder an Hand vorhandener Bilder zu erzeugen. Beide Filterarten benutzen fr die Filteroperation die erwhnten Bewegungsvektoren sowie die Vorgnger- und Nachgngerbilder des zu filternden Bildes. Der Zwischenzeilenfilter benutzt noch zustzlich die Information aus dem Zwischenzeilenbild, das in ein Progressivbild gewandelt wird. Zustzlich existieren Eingabe- und Ausgabekomponenten zum Einlesen und Ausgeben von Bildern. In den folgenden Abschnitten werden die Bewegungsschtzung- und Filterungsstrategien im Detail besprochen.

Anhang A: Handbuch fr den Simulator

4.1 Bewegungsschtzung
Der Bewegungsschtzer ist verantwortlich, fr jeden Bildpunkt des untersuchten Bildes einen Vektor zu liefern, der Aussage darber treffen kann, wie schnell und in welche Richtung sich dieser Bildpunkt bewegt. Die Kosten zur expliziten Bearbeitung jedes Bildpunktes sind fr eine Echtzeitberechnung in einem ASIC wie HiCon jedoch zu hoch. Die Eingabebilder fr die Bewegungsschtzung werden in quincunx Muster unterabgetastet (siehe Abbildung 9). Der Bewegungsschtzer von HiCon operiert ferner auf Blcken von Bildpunkten. Die Gre eines Blockes ist wahlweise 2x2,4x4 oder 8x8. Die aktuelle Voreinstellung fr einen Block betrgt 4x4 Bildpunkte.
Q
( 0

u
, 0 )

i n

t e N r a o b n t qa us it nu qn ug n
( 0 , 0 )

t e

r a

t a

s t u

Abbildung 9: Quincunx Unterabgetastete Bilder als Eingabe der Bewegungsschtzung.

Ferner ist der Bewegungsschtzer in der Lage, ein oder zwei Messbilder in die Schtzung einzubeziehen und hat die Fhigkeit vorwrts sowie rckwrts zu schtzen. Im folgenden werden die Bezeichnungen R fr das zu untersuchende Bild, M1 fr das neueste Messbild und M2 fr das ltere Messbild benutzt. Diese Betrachtung gilt fr eine Rckwrtsschtzung ber zwei Vorgngerbilder. Bei einer Vorwrtsschtzung mssen die Bedeutungen von M1 und M2 vertauscht werden (Abbildung 10).

10

Stand der Technik

Z R c k w r t s s c h t z u n g V o r w r t s s c h

it t z u n g

Abbildung 10: Die bentigten Bilder fr die Bewegungsschtzung.

Die Bewegungsschtzung liefert Vektoren, die von R nach M2 zeigen. Diese Vektoren sind auf R skaliert. Fr den Fall, dass R ein Halbzeilenbild ist, sind die Vektoren bezogen auf ein Progressivbild bildpunktgenau. Der Algorithmus fr die Bewegungsschtzung arbeitet manderfrmig und beginnt mit dem oberen linken Block. Durch den Umstand, dass die Abarbeitungsrichtung sich mit jeder neuen Zeile ndert, wird die Effizienz des Algorithmus noch weiter verbessert (Abbildung 11). Um einen Bewegungsvektor fr einen Block zu bestimmen, werden die Nachbarschaftsvektoren des Blockes sowie der Vektor aus dem letzten Bild fr diesen Block in die engere Wahl gezogen. Diese Vektoren werden dann auf die nachfolgenden Bilder angewandt und durch Blockvergleiche berprft und durch Interpolationsstrategien weiter verfeinert. Der beste Kandidat fr diesen Block wird als Blockvektor ausgewhlt. Die Einheit ist ebenfalls in der Lage, eine Aussage ber die Zuverlssigkeit der erzeugten Vektoren zu treffen. Da letztlich fr die weitere Filterung bildpunktgenaue Vektoren ntig sind, werden die Blockvektoren anschlieend durch die Anwendung von einem 2-Schritt Medianfilters in bildpunktgenaue Vektoren verfeinert. Somit steht fest, dass die Zuverlssigkeit der Vektoren eine wichtige Rolle bei der Qualitt der Formatkonvertierung spielt. Fr den Fall, dass die Vektoren nicht sehr genau sind aber trotzdem als zuverlssig eingestuft wurden, werden die fr die Filterung ausgesuchten Bildpunkte aus nicht optimalen Bildbereichen ausgewhlt. Werden aber die Vektoren als unzuverlssig erkannt, findet die Konvertierung der betroffenen Bilder mehr rtlich als zeitlich statt. Das fhrt bei einer solchen Konfiguration zu besseren Resultaten.

11

Anhang A: Handbuch fr den Simulator

X O

Z A

r t lic h e r V o r g n g e r e it lic h e r V o r g n g e r k t u e lle r B lo c k

Abbildung 11: Die Vektorkandidaten bei der manderfrmigen Bewegungsschtzung.

4.2 Die Filterung


Die erhaltenen Vektoren bilden die Basis fr die nachfolgenden Filteroperationen. Der Blockvektor wird fr die weiteren Filteroperationen mit Hilfe eines zweistufigen Medianfilters in Bildpunktvektoren berfhrt. Der resultierende Bildpunktvektor zeigt fr jeden gewnschten Bildpunkt die Bewegungsinformation an. Dieser Vektor muss jedoch noch auf die Zeitphase des Ausgabebildes skaliert werden. Es werden zwischen zwei Arten der Filterung unterschieden:

4.2.1 Die Zwischenbildfilterung


Bei der Zwischenbildfilterung wird ein neues Bild unter Verwendung von zwei Eingabebildern erzeugt. Das Vorgnger- und Nachfolgereingabebild, die Bewegungsvektoren sowie deren Gltigkeitsinformationen werden fr diese Operation bentigt. Die zeitliche Lage des zu erzeugenden Bildes erfordert eine Skalierung der Bewegungsvektoren zu den umgebenden Referenzbildern. 12

Stand der Technik

Abbildung 12: Die Zwischenbildfilterung. Die Informationen in den runden Abbildungen dienen als Detailansicht der mit X markierten Bereiche der Bilder in der oberen Reihe. Die grauen Pfeile illustrieren die Bewegungsvektoren.

Um einen Bildpunkt an der Position (x,y) zu berechnen, wird aus dem Ausgabebild der schon berechnete Bildpunkt an der Position (x,y-1) genommen. Der Einfluss dieses Punktes in die Filterung hngt von der Gte der Vektoren ab. Bei ungltigen Vektoren liegt die Gewichtung auf diesem Bildpunkt. Anschlieend werden die skalierten Bildpunktvektoren bei den umgebenden beiden Eingabebildern auf die Position des zu erzeugenden Bildpunktes (x,y) addiert. An den nun erhaltenen Positionen (xv,yv) fr das Vorgngereingangsbild und (xn,yn) fr das Nachfolgereingangsbild werden nun in einem Plusmuster jeweils fnf Bildpunkte (an den Positionen (xv-1,yv), (xv,yv), (xv+1,yv), (xv,yv-1), (xv,yv+1) sowie (xn-1,yn), (xn,yn), (xn+1,yn), (xn,yn-1), (xn,yn+1))genommen, wobei der mittlere Bildpunkt (xv,yv) und (xn,yn) mit der Gewichtung von fnf Bildpunkten behaftet wird (siehe Abbildung 12). Der zu erzeugende Bildpunkt wird durch die Filterung aller dieser Bildpunkte ermittelt. Die dabei verwendete Filteroperation ist eine Kombination aus Median- und Bilinearfilterung. Die Abarbeitung eines Bildes erfolgt bildpunktweise von links nach rechts bei jeder Zeile eines Streifens. Die Zeilen werden von oben nach unten 13

Anhang A: Handbuch fr den Simulator abgearbeitet. Dabei wird das Bild in Streifen variabler Breite unterteilt. Die Abarbeitung der Streifen beginnt mit dem linken Streifen (siehe Abbildung 13).

t r e

i f e

S1

t r e

i f e n

Abbildung 13: Die streifenweise Abarbeitung.

4.2.2 Die Zwischenzeilenfilterung


Durch die Zwischenzeilenfilterung ist es mglich, auf Halbbildern basierende Eingangsbilder in Vollbilder um zu wandeln. Fr diese Operation werden wie bei der Zwischenbildfilterung Vektoren, deren Zuverlssigkeitsinformationen, Bildpunkte aus dem Vorgnger- sowie Nachfolgereingangsbild und speziell fr diese Operation die vorhandenen Daten des umzuwandelnden Halbbildes bentigt. Da das zu filternde Halbbild genau zwischen zwei Eingangsbildern liegt, mssen die Vektoren nicht gesondert skaliert werden.

14

Stand der Technik

in

g n + 1a

i n

gn a

i n

g n + 1a

s gn a

n g

Abbildung 14: Die Zwischenzeilenfilterung

Um wiederum einen Bildpunkt an der Position (x,y), wobei y eine nicht vorhandene Zeile des Bildes ist, zu berechnen, werden aus dem zeitlich berlappenden Halbbild zwei Bildpunkte mit (x,y-1) und (x,y+1) genommen. Wie bei der Zwischenbildfilterung stellen diese Punkte die rtliche Komponente dar und werden somit bei unzuverlssigen Vektoren mit hoher Gewichtung in die Filterung einbezogen. Aus dem Vorgnger- und Nachfolgerbild werden an den Positionen (xv,yv) und (xn,yn), das durch eine Addition bzw. Subtraktion des Vektors entstehen, jeweils vier Bildpunkte in einem Quadratmuster genommen (siehe Abbildung 14). Diese Bildpunkte erzeugen nach einer mehrstufigen Filterung den gewnschten Bildpunkt des Vollbildes.

15

Anhang A: Handbuch fr den Simulator

5 Der Aufbau des ASIC


Der HiCon Formatkonverter wird als eine Einchip Lsung angestrebt. Auf der Systemplatine werden nur noch verschiedene Speicherbausteine bentigt. HiCon hat eine Parallelarchitektur, die es zulsst gleichzeitig: o ein Eingabebildpaar (bestehend aus Luminanz- sowie Chrominanzanteil) einzulesen und bei Bedarf zu skalieren, o einen Ausgabebild (bestehend aus Luminanz- sowie Chrominanzanteil) bei Bedarf skaliert auszugeben, o die Bewegungsschtzung fr ein eingegebenes Bild durchzufhren, o eine Halbbild/Vollbild Wandlung durchzufhren (alternativ kann ein minderqualitatives Zwischenbild berechnet werden), o ein hochqualitatives Zwischenbild zu berechnen. Abbildung 15 illustriert den Aufbau des ASIC auf Systemebene. Alle Kernkomponenten des ASIC operieren auf folgendem Prinzip: Wenn die Einheit bereit ist, wartet sie auf Betriebsparameter und ein Startsignal. Sobald die Einheit ihr Startsignal erhlt, ist sie solange beschftigt, bis die Ausgabe vollstndig erzeugt ist. Nach dem Erzeugen der Ausgabe meldet sich die Einheit als fertig zurck. An dieser Stelle knnen Rckgabeparameter ausgelesen werden. Danach wiederholt sich der Zyklus. Die Ausgabe ist in der Regel ein Bild. Die einzige Ausnahme bildet die Bewegungsschtzung, die Bewegungsvektorfelder erzeugt. Dabei knnen die einzelnen Komponenten die Formatkonversion nicht selbstndig ausfhren. Dies ist die Aufgabe der Systemkontrolle, da die Einheiten nicht wissen, in welchem Gesamtkontext ihre aktuelle Aufgabe steht. Als Beispiel kann eine Filtereinheit nicht bestimmen, welches Bild sie anhand anderen Hilfsbildern filtern kann. Sie wei ferner auch nicht, in welchem Kontext die Daten stehen, die sie bekommt. 16

Stand der Technik

r b e i t s s p e B i c o h o e t r- R

S y s t e m -E k o n t r o lleE

x t e r n e / A S c h n T i t to s t e ll e n

n d a t e V en
u

u d i o r z g e T r -o n n g s e in h e it

d a t e

P E

a r a m e t e in h e it
P

r -

a r a m e t e r b e r g e b e r

a r a m e t e P r a- r a m e t e P r a- r a m e t e P r a- r a m e t e P r a- r a m e t e r b e r g e b e r b e r g e b e r b e r g e b e r b e r g e b e r b e r g e b e r

ild s e q

u EE e ii nn n gh zae

i Bb ee -w e g Z ne g l es n f Bi l t i el d r f- i l t eA r u- s g a b e u si t c h t z e E r i n h e i t E i n h e i tE i n h e i t B

ild

s e

q u e n z

E E C S

i n g i n h a c p e

bB e e - w e is t c h t h e C- a c h i c hS e p r e i c a e

g z e h

Zu e ig l es n f B l n i eE r i - n h e i t E -C a c h e -C S rp e i c h S e e

t ie l d r -f i l t e A r i n h e i tE a c h e Crp e i c h S e

uin a pr

s g a b e h e it c h e e ic h e r

- R

o n t r o

ll e

- R

I C

a t e

n s p e ic h e

Abbildung 15: bersicht von HiCon auf toplevel Systemebene.

17

Anhang A: Handbuch fr den Simulator Im folgenden werden die einzelnen Einheiten erlutert. Dabei werden nur die Ein- und Ausgnge der zu bearbeitenden Daten eingezeichnet. Die Leitungen zur Parametrisierung der Einheiten werden nicht illustriert:

5.1 Frontend Einheit


Sie ist zustndig fr das Einlesen und das gleichzeitige Skalieren von Eingansbildern (siehe [6]). Diese Einheit erzeugt bei dem Einlesen der Eingangsbilder gleichzeitig auch die fr die Bewegungsschtzung wichtigen quincunx unterabgetasteten Bilder. Weiter kann diese Einheit sogenannte Szenenwechsel in der Sequenz detektieren. Der Begriff Szenenwechsel besagt, dass zwei nachfolgende Eingangsbilder keine kontinuierliche Bewegung darstellen. Dieses Phnomen tritt in der Regel dann auf, wenn das Bildmaterial einen Schnitt oder eine berblendung enthlt (siehe Abbildung 16).

E i n g a n g L u m i n a n E i n g a n g C h r o m i n

F r o n t e s U b n i l id t z s b il d a n z

E i n g L u m d E i n g C h r o Q u i n N o n

a i n a m c q u

g s b il d n z n g s b il d i n a n z u n x a i n c u n x

Abbildung 16: Ein- und Ausgnge der Frontend Komponente.

5.2 Bewegungsschtzer
Der Bewegungsschtzer liefert die Bewegungsvektoren fr ein eingelesenes Bild. Er braucht vier unterabgetastete Bilder der zeitlichen Vorgnger (2xBildn, 1xBildn-1 und 1xBildn-2) sowie die Vorgngervektoren, um die Ausgabevektoren zu erzeugen. Auerdem gibt er Auskunft ber die geschtzte Zuverlssigkeit der Vektoren (siehe Abbildung 17). 18

Stand der Technik

Q N Q Q o

u n u u

i n

c u q u

M o t i o n a n E sn t i m x U n i t i n c u n x n n x n n - 1 - 2

t i o

i n

c u

i n c u

n x

k t o

r e

k t o

r e

- 1

Abbildung 17: Ein- und Ausgnge der Bewegungsschtzer Komponente.

5.3 Zeilenfiltereinheit
Die Zeilenfiltereinheit wird hauptschlich fr die Halbbild/Vollbild Filterung benutzt. In diesem Betriebsmodus werden die fehlenden Zeilen der Eingangsbilder erzeugt. Die Einheit braucht hierfr das Vorgnger- sowie Nachfolgerbild, die Bewegungsvektoren, deren Zuverlssigkeiten und das vorhandene Halbzeilenbild, welches ergnzt wird. Das Parametrisieren und Starten der Einheit erzeugt das gewnschte Ausgangsvollbild. Dabei wird das schon eingelesene Halbbild im Speicher beibehalten, whrend ein weiteres Halbbild mit den fehlenden Zeilen erzeugt wird (siehe Abbildung 18). Alternativ kann die Einheit auch dafr benutzt werden, um ein minderqualitatives Zwischenbild zu generieren. Dieser Modus wird hauptschlich fr die Zwischenbildgenerierung der Chrominanzbilder eingesetzt. In dem alternativen Modus beschrnkt sich die Eingabe auf das Nachfolgebild, sowie Vektoren und Zuverlssigkeit.

19

Anhang A: Handbuch fr den Simulator

V o r g n g e r E i n g a n s bI n i l t d e r l i n F il t e r N a c h f o lg e r U n i t E i n g a n s b il d A E V e k t u i n g k t o e a l le r n s b r e n il d

A A

u u

s g s g

a a

n g n g

s b i l d s b i l d

1 2

Abbildung 18: Ein- und Ausgnge der Zwischenzeilenfilter Komponente.

5.4 Zwischenbildfilter
Der Zwischenbildfilter erzeugt zustzliche hochqualitative Zwischenbilder anhand von Sttzbildern und Vektoren. Hierbei wird auf Vorgnger- und Nachfolgerbild operiert. Unter Zuhilfenahme von Vektoren und Gtebits generiert die Einheit in einem Durchlauf ein bis zwei Zwischenbilder (siehe Abbildung 19).

V o r g n g E i n g a n g N a c h f o l E i n g a n g V e k t o

e I s F gU s

t e r f r a il d i lt e r e nr i t b i ld b

e A A

u u

s g s g

a a

n g n g

s b

i l d

1 2

r e n

s b i l d

Abbildung 19: Ein- und Ausgnge der Zwischenbildfilter Komponente.

20

Stand der Technik

5.5 Ausgabeeinheit
Die Ausgabeeinheit bernimmt die bildweise Ausgabe der fertig berechneten Sequenz (siehe [6]). Sie kann Halbbilder sowie Vollbilder ausgeben, und kann diese Bilder whren der Ausgabe skalieren. Die Bildausgabe luft asynchron zum Einlesen der Eingabebilder (siehe Abbildung 20).

B B C

i ld i ld h r o

u m

B U

i n a n z a c k e n d n i t a n z

i n

B i ld L u m i n a n z S k a l i e r t B i ld C h r o m i n a n z s k a l i e r t

Abbildung 20: Ein- und Ausgnge der Backend Komponente.

5.6 Audioverzgerungseinheit
Die Audioverzgerungseinheit ist kein Teil der Formatkonvertierung, da HiCon die Toninformation nicht anreichert. Deshalb wird sie im Weiteren nicht als Kerneinheit bezeichnet. Sie dient zur Verzgerung der mit den Bilddaten eingehenden Toninformation. Als die Dauer der Verzgerung wird die Latenzzeit der HiCon Pipeline herangezogen (Die Zeit, die zwischen dem ersten Einlesen und der ersten Ausgeben der Bilder verstreicht). Sie funktioniert im Groben wie ein skalierbares Fifo Speicher (siehe Abbildung 21).

T o n

a t e

A n U

u d io n it

v e

r z g e r u n g s V e r z g e r t e T o n d a t e n

Abbildung 21: Ein- und Ausgnge der Audioverzgerung Komponente.

21

Anhang A: Handbuch fr den Simulator

5.7 Parametereinheit
Die Parametereinheit dient zur Kommunikation zwischen der Systemkontrolle und den verschiedenen Komponenten von HiCon. Durch diese Einheit ist die Systemkontrolle in der Lage, die Komponenten zu parametrisieren und zu starten sowie Rckgabeparameter von den Komponenten einzulesen. Die Speicherverwaltung und die Partitionierung des HiCon Datenspeichers wird ebenfalls ber diese Einheit abgewickelt (siehe Abbildung 22).

B S y s te m s te u e ru n g S D D

e t a a a

f e h t u t e t e

l s rP e a g r i as tm e U n i t s r e g is t e r g g is t e r is t e r

e r

t e r H iC O N

n r e n r e

1 n

r a

t e r

Abbildung 22: Schematische Darstellung der Parametereinheit/Systemkontrolle/Kern-Verschaltung.

5.8 Parameterbus
Die Parametertransfereinheit verwendet den Parameterbus, um den chipinternen Steuerfluss zu ermglichen. Der Bus ist als Daisy-Chain-Bus konzipiert und implementiert. Fr jede Komponente bzw. jeden Kommunikationspartner ist eine Parameterschnittstelleneinheit in den Bus eingefgt. Diese steuert den bidirektionalen Parametertransfer von bzw. zu den jeweiligen Komponenten von HiCon. Die Datenpakete mit einer Einheitsidentifikationsnummer versehen und in den Bus gelegt werden. Diese werden dann solange weitergereicht, bis die adressierte Einheit die Daten abnimmt. Der Bus startet und endet bei der Parametereinheit (siehe Abbildung 23). 22

Stand der Technik

E A P P a r a G m e a r a m r e t e r E in h

in

e it

e i t r

t r ie s ie r e

r a A

t r ie s ie r e

r a F

t r ie s ie r e

r a B

t r ie s ie r e

r a E

t r ie s ie r e

r a m C r

t r ie s ie r e

r a m D

t r ie s ie r e

Abbildung 23: Der Parameter Bus ist als Daisy-Chain-Bus implementiert.

5.9 Datenspeicher (Bildspeicher)


Der Speicher fr alle mglichen Eingangs-, Ausgangs- und Zwischenbilder sowie Vektoren ist in Form eines SDRAM Speichers mit ASIC interner Verwaltungslogik realisiert. Dabei kann der Speicher von der Systemkontrolle beliebig partitioniert werden. Der Speicherkontroller ordnet dem in Segmenten partitionierten Speicher in fortlaufende Nummerierung zu. Da die HiCon Kernkomponenten nicht explizit wissen, auf welche Bilder der Sequenz sie operieren, ist die SDRAM Kontrolle die Instanz, die einer Einheit die richtigen Daten zuordnet. Dabei werden die Nummern der Speichersegmente mit der Identifizierungsnummer der Einheit assoziiert. Die Systemkontrolle ist die einzige Instanz, die eine Art Buchfhrung betreibt, welche Einheiten ber welche Speichersegmente auf welchen Bildern der Sequenz operieren (siehe Abbildung 24).

23

Anhang A: Handbuch fr den Simulator


A k t i o n : A k t i o n : p o n e D a t e n l e s f e nr / K o m v o n / z u S e g m s c h r e i b e n

n e

t e A n S t Dk S e g

D a t e n i - l R e Af e M r n m e n t 1

H K

i C O N o m p o

t e

S D - R A M KA o n t r o l l e

S e g m ( 1 < k < B i ld X

e n t k n ) m i t

y s t e

k o n

t r o S

ll e e g

n t

A k t i o n : S e g m e n t k f r E i n h e i t A r e s e r v i e r e n w e i l K o m p o n e n t e A a u f B i l d X o p e r i e u n d S e g m e n t k B il d X b e i n h a lt e t
Abbildung 24: Speicherverwaltung aus drei Sichten: i) Die HiCon Kerneinheit greift auf seine Daten zu, ohne die Information zu besitzen, in welchen Segment sie liegen oder welches Bild ihnen zugeordnet ist. ii) Der Speicherkontroller assoziiert Segmente mit HiCon Komponenten, ohne die Inhalte der Segmente zu kennen. iii) Die Systemkontrolle kennt Inhalt der Segmente und veranlasst den Speicherkontroller, verschiedene Segmente auf die Kerneinheiten umzuleiten.

24

Stand der Technik

5.10 Datenbus
HiCon besitzt einen zentralen bidirektionalen Datenbus. Hierber wird der Datenverkehr mit Hilfe eines speziellen Busprotokolls abgewickelt. Jede Komponente von HiCon, die am Bus angeschlossen ist, hat eine explizite Anfrageleitung. Mit Hilfe der Anfrageleitung kann, je nachdem in welchem Kontext die Einheit mit dem Bus verschaltet ist, eine Anfrage auf Datenlesen bzw. Schreiben gestellt werden. Der Speicherkontroller wiederum hat zur jeden Komponente eine explizite Zusageleitung, mit der die Anfrage besttigt wird. Die Daten werden mit Hilfe eines ebenfalls expliziten Transfersignals zu der jeweiligen Komponente gesendet bzw. von ihr empfangen. Es kommt deshalb zu undeterministischem Busverhalten, indem Wartezeiten am Bus entstehen (siehe Abbildung 25).

A Z T A Z T n u r a f r a g s a g e e S p e ic h e r k o n tr o lle r

n u r a

f r a g s a n s f e A A o

e r

B B B K o m p o n e n t e B

g e

n s Kf e o r m A p

n e

t e

n t r a

le

t e

Abbildung 25: Der zentrale bidirektionale Datenbus mit separaten Kontrollleitungen zu jeder Kernkomponente.

5.11 Einheitenzwischenspeicher
Die Einheitenzwischenspeicher sind intelligente Speicher, die Einheiten mit Daten beliefern. Sie stehen zwischen dem SDRAM Bildhauptspeicher und der jeweiligen 25

Anhang A: Handbuch fr den Simulator Einheit. Die Idee hinter diesem Konzept ist, dass die intelligenten Zwischenspeicher die Daten soweit wie mglich im voraus laden bzw. speichern. Somit knnen die Einheiten mglichst ohne Wartezeiten operieren. Dabei benutzen die Zwischenspeicher das Cachingprinzip. Der Datenaustausch zwischen den Einheitenzwischenspeichern und dem Bildhauptspeicher geschieht burst weise.

26

Stand der Technik

6 Theoretische Betrachtung zu den Aufgaben der Systemkontrolle

6.1 Die Generierung der Ausgabesequenz

6.1.1 Das Wandlungsverhltnis


Unbeachtet der ntigen Zwischenschritte die bis zum Erzeugen eines Ausgabebildes ntig sind, ist das Wandlungsverhltnis eine wichtige Gre bei der Formatkonvertierung. Das Wandlungsverhltnis W ist das Verhltnis zwischen der Eingangsfrequenz und der Ausgangsfrequenz. Daher: W = Eingangsfrequenz/Ausgangsfrequenz. Anhand von W kann man folgende pauschale Aussagen treffen. I. Ist W>1 werden Bilder reduziert. D.h., wir verwerfen Bilder der Eingangsequenz und geben somit weniger Bilder aus, als wir einlesen. II. Ist W = 1 liegt keine Wandlung vor. Die Sequenz wird (bzgl. Bildgenerierung) unverndert ausgegeben. III. Ist W<1 werden Bilder generiert und somit die Eingabesequenz bereichert. Das ist die eigentliche Aufgabe von HiCon.

6.1.2 Die visuelle Notation


Als ein visuelles Modell fr Sequenznotation betrachte man einen eindimensionalen Raum, welcher die Zeit abbildet. Entlang dieser Zeitachse werden an ganzzahligen 27

Anhang A: Handbuch fr den Simulator Stellen die Eingansbilder eingetragen. Anbei werden die Eingangsbilder mit einer fortlaufender Identifikationsnummer notiert. Die Identifikationsnummer wird beginnend von Eins in Einerschritten hochgezhlt (siehe Abbildung 26).

N Z e it ( t )

Abbildung 26: Die vertikalen Balken stellen die Bilder der Eingangssequenz dar.

6.1.3 Der Bindungsbereich der Sttzbilder und die Positionen zur Bildgenerierung
HiCon bietet zwischen zwei Eingangsbildern eine endliche Anzahl von Positionen, an denen Bilder generiert werden knnen. Zur Zeit sind 31 Stellen zwischen den Sttzbildern (Eingangsbildern) vorgesehen (siehe Abbildung 27).

1 Z e

it ( t )

1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1

Abbildung 27: 31 mgliche Positionen zum erzeugen der Knstlichen Bilder befinden sich zwischen zwei Eingansbildern.

Jedes Sttzbild hat einen bestimmten Bindungsbereich. Um den Bindungsbereich eines Sttzbildes herum wird das jeweilige Sttzbild als primre Referenz genommen, in dem 28

Stand der Technik die Bewegungsvektoren dieses Sttzbildes fr die weiteren Berechnungen benutzt werden. Die Positionen im Bindungsbereich des Sttzbildes, die zeitlich vor dem Sttzbild auftreten, werden mit negativen Vorzeichen behaftet. Analog dazu werden die Positionen, die zeitlich nach dem Sttzbild auftreten, mit positiven Vorzeichen annotiert (siehe Abbildung 28). Somit entstehen zwar zwischen zwei Sttzbildern 31 mgliche Positionen zur Bildgenerierung, aber diese Positionen werden zwischen den beiden Sttzbildern aufgeteilt.

1 5

1 Z e

it ( t )

1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 0 - 1 6

Abbildung 28: Die Positionen haben verschieden Zugehrigkeiten.

Wenn also ein Sttzbild n betrachtet wird entsteht das in Abbildung 29 dargestellte Szenario.

N + 1 + 1 5

- 1 6

- 1

Abbildung 29: Der komplette Bindungsbereich eines Eingabebildes.

Im weiteren wird eine 2-Tupel Notation (B,P) fr alle Arten von Bildern eingefhrt. Dabei steht der erste Term B fr die Identifikationsnummer des gebundenen Sttzbildes und der zweite P Term fr die oben genannte Position. Bei Eingangsbildern ist P und damit die Position immer gleich null. Das Wandlungsverhltnis W ist fr die folgenden Betrachtungen wichtig. 29

Anhang A: Handbuch fr den Simulator

Betrachtet man nun als Beispiel eine 75Hz zu 100Hz Wandlung bekommt W den Wert . In Abbildung 30 wird die Eingangssequenz sowie die Ausgangssequenz dargestellt.

E in g ( 1 , 0 )

n s s e (2 , 0 )

u e

n z ( 4 , 0 ) ( 5 , 0 ) ( 6 , 0 )

( 3 , 0 )

( 1 , 0 )( 2 , - 8 ( ) 3 , - 1 ( 6 ), 8 ) ( 4 , 0 ) ( 5 , - 8 ( ) 6 , - 1 ( 66 ), 8 ) 3 A u s g a n g s s e q u e n z

Abbildung 30: Die Eingangs- (oben) sowie Ausgangssequenz (unten) bei einer Wandlung. Die groen vertikalen Balken stellen die Eingangsbilder (Sttzbilder), die gestrichelten groen vertikalen Balken die Eingansbilder, die nicht ausgegeben werden und die kleinen vertikalen Balken die knstlich erzeugten Bilder dar.

Die gestrichelten Linien in der Ausgabesequenz stellen Eingabebilder dar, die verworfen werden. Die Ausgabesequenz besteht somit aus Eingabebildern sowie generierten Bildern. Die Eingabe- sowie Ausgabesequenz knnen wie folgt gebildet werden. Fr n+ und P,B gilt fr die Eingabesequenz: Sei G(x) eine Funktion, die eine reelle Zahl in die entsprechende Ganzzahl abbildet. So ist: E(1) = 1 und E(n) = E(n-1) + 1. Sowie fr die Ausgabesequenz: A(1) = E(1) = 1 und A(n) = A(n-1) + W. Wenn A(n) ein Ganzzahlwert liefert wird von der Eingabesequenz E(A(n)) fr A(n) bernommen. 30

Stand der Technik Um die Position P und Bindung B fr ein Element A(n) der Ausgabesequenz zu ermitteln gilt: P = G((A(n) G(A(n)) )* 32) B = E(G(A(n))) P = G((A(n) G(A(n)))* 32)- 31 B = E(G(A(n))+1) , sonst. , wenn 0(G((A(n) G(A(n)))*32))15

In der gegenwrtigen Version des Formatkonverters werden die generierten Bilder mit Positionen 5<P<+6 durch Sttzbilder ersetzt, oder, mit anderen Worten, werden diese Positionen stets auf die Position 0 korrigiert. Diese Korrektur gewhrleistet, dass stets gengend Originalbilder in der Ausgabesequenz vorhanden sind. Bei sehr kleinen Werten fr W (z.B. 1/64), wo eine Addition von A(n-1) mit W keine Positionsberschreitung bewirkt, werden an denselben Positionen mehrere Bilder ausgegeben. Diese Bilder brauchen nicht mehrfach generiert werden, sie werden lediglich mehrfach ausgegeben. Bei W>1 kommt es vor, dass B sich um mehr als Eins erhht. Auch wenn bei der Runterkonvertierung Eingabebilder verschluckt werden, werden die nicht ausgegebenen Eingabebilder zum Erzeugen der Zwischenbilder gebraucht. Bei W=1, sofern die Eingangskodierung gleich der Ausgangskodierung ist (Vollbild- oder Halbzeilenkodiert), wird der Konverter deaktiviert und durch eine Bypassschaltung umgangen.

6.1.4 Ausnahmebehandlung bei Movie Mode


Beim Movie Mode kommen jeweils zwei halbzeilenkodierte Eingangsbilder, die zusammen ein Vollzeilenbild ergeben, nacheinander herein. Somit ist die zeitliche Position der beiden Eingangsbilder identisch. Daraus ergibt sich, dass die Eingangsfrequenz und somit W sich effektiv halbieren.

31

Anhang A: Handbuch fr den Simulator

7 Spezifikation der Systemkontrolle

7.1 Generelle Betrachtungen


Die Systemkontrolle von HiCon ist dafr zustndig, die Formatkonvertierung als solche mit den zur Verfgung stehenden HiCon Komponenten durchzufhren. Dabei ist der ASIC bezglich der Ressourcen in Form von Bildern und Vektoren, die gleichzeitig im Datenspeicher gehalten werden knnen, stark limitiert. Da die Formatkonvertierung in Echtzeit durchgefhrt wird, spielt die zgige Bearbeitung eine wichtige Rolle. Die Systemkontrolle muss daher schnell und optimal handeln knnen. Die Aufgaben, welche die Systemkontrolle zu bewltigen hat, knnen grob in zwei Modi aufgeteilt werden. Diese Modi beziehen sich auf die Kodierung der Eingabesequenz, die entweder halbbildkodiert oder vollbildkodiert anliegen kann. Diese Modi werden im weiteren wie folgt benannt: Der Progressivmodus (Vollbildmodus) Der Interlacedmodus (Halbbildmodus)

Die beiden Modi lassen sich wegen der unterschiedlichen Bildgren und Wandlungsschritte nicht ohne weiteres miteinander vereinen. Bei dieser Betrachtung spielt die Partitionierung des Datenspeichers eine wesentliche Rolle. Wie schon im Kapitel 5.9 erwhnt wurde, wird der HiCon Datenspeicher von der Systemkontrolle partitioniert. Bei der Partitionierung wird der Speicher in Segmente unterteilt. Die einzelnen Segmente werden fr die Speicherung der Bilder und Vektoren bentigt. Die oben benannten Modi erzwingen jedoch eine jeweils andere Partitionierung des Speichers, wenn man den Speicher nicht unntig vergrern mchte. Dies ist zum einen in einen wegen der unterschiedlichen maximalen Gre der Bilder, zum anderen aber auch in der unterschiedlichen Anzahl der bentigten Segmente begrndet. Aufgrund seiner vollbildkodierten Eingangsbilder erfordert der Progressivmodus 32

Stand der Technik Speichersegmente mit vergleichsweise grerer Kapazitt als der Interlacedmodus. Anderseits entfllt beim Progressivmodus das Deinterlacing und somit entfallen gleichzeitig die fr die Speicherung der Resultate dieser Operation notwendigen Segmente. Da bei der Umpartitionierung des Datenspeichers alle Informationen in den jeweiligen Speichersegmenten unbrauchbar werden, ist ein flieender bergang zwischen den beiden Modi unmglich. Somit mssen die Modi separat behandelt und als exklusive Unterprobleme des Gesamtproblems der Systemkontrolle betrachtet werden. Bevor jedoch auf die jeweiligen Differenzen der beiden Modi eingegangen wird, wird auf die Gemeinsamkeiten der Modi eingegangen.

7.2 Operationen fr beide Modi


7.2.1 Algorithmus fr die Berechnung der bentigten Zwischenbilder
Die Ermittlung der zu generierenden Sttzbilder ist eine modebergreifende Operation. Sie basiert auf der im Kapitel 6 vorgestellten theoretischen Betrachtung. Somit muss ein Mechanismus erzeugt werden, der fr ein sich in der Pipeline befindliches Sttzbild die zu generierenden Zwischenbilder ausgibt.

7.2.2 Speicherverwaltung in der Systemkontrolle


Um die Formatkonvertierung durchzufhren, muss die Systemkontrolle ein Abbild der Belegung des Datenspeichers beinhalten. Das Abbild muss Informationen ber folgende Zusammenhnge liefern: Die Partitionierung des Speichers in Segmente. Welche Segmente welche Datentypen beinhalten. Welche Segmente mit welchen Daten zu einem Zeitpunkt t belegt sind und

welche Segmente fr weitere Operationen freistehen. Welche Einheiten zu einem Zeitpunkt t an welchen Segmenten arbeiten.

33

Anhang A: Handbuch fr den Simulator

7.2.3 Lesen der Eingangsbilder


Jedes Bildpaar der Eingabesequenz bestehend aus Luminanz- und Chrominanzanteil muss mittels der Frontend Einheit eingelesen werden. Falls die Bildgre die Segmentgre bersteigt, ist ferner eine Skalierung beim Einlesen ntig. Die Eingangsdaten kommen in regelmig periodischen Abstnden abhngig von der Eingabefrequenz (siehe Tabelle 1).

Tabelle 1: Zusammenfassende Spezifikation der Eingangsdatenbehandlung.

Bentigte Komponente Bedingung Bentigte Segmente

Frontend Immer wenn Eingangsbilder einkommen. 1x(schreiben) Luminanzanteil von Bild n. 1x(schreiben) Chrominanzanteil von Bild n. 1x(schreiben) Quincunx unterabgetastetes Bild n. 1x(schreiben) Nonquincunx unterabgetastetes Bild n. Wert fr die Detektion eines Szenenwechsels.

Rckgabewerte

7.2.4 Erzeugen der Blockvektoren


Die Blockvektoren werden unabhngig vom Modus fr jedes Eingangsbild erzeugt. Hierbei gilt zu beachten, dass der Bewegungsschtzer einen Wert fr die Qualitt der Vektoren bergibt. Dieser Wert wird mit einer vom Modus abhngigen Schwelle verglichen, um die Gltigkeit der Blockvektoren einzustufen (siehe Tabelle 2).

Tabelle 2: Zusammenfassende Spezifikation der Bewegungsschtzungsbehandlung.

Bentigte Komponente Bedingung Bentigte Segmente

Bewegungsschtzer Fr jedes eingelesene Eingangsbild. 1x(schreiben) Blockvektoren fr Bild n. 1x(lesen) Blockvektoren von Bild n-1. 1x(lesen) Quincunx unterabgetastetes Bild n. 1x(lesen) Nonquincunx unterabgetastetes Bild n. 34

Stand der Technik 1x(lesen) Quincunx unterabgetastetes Bild n-1. Rckgabewerte 1x(lesen) Quincunx unterabgetastetes Bild n-2. Gre fr die Gltigkeit der Blockvektoren.

7.3 Vom Modus abhngige Operationen

7.3.1 Finden von konsistenten Operationszyklen


Um die Gre des Datenspeichers konstant zu halten und um einen kontinuierlichen Ausgabestrom zu gewhrleisten, muss pro eingelesenem Eingabebild mit der parallelen Architektur des ASIC in Abhngigkeit von Wandlungsverhltnis die Ausgabe der zu einem Sttzbild gehrenden Zwischenbilder und des Sttzbildes (siehe Kapitel 6) erfolgen. Ansonsten wrden in absehbarer Zeit keine freien Segmente fr weitere Bilder verbleiben. Vorraussetzung dafr ist, dass fr jedes Eingangsbild die Blockvektoren fr das vorangegangene Eingangsbild erzeugt werden. Ferner muss im Interlacedmodus fr ein frheres Sttzbild ein Deinterlacing stattfinden. Gleichzeitig mssen die zu dem in der Pipeline befindlichen Sttzbild gehrenden Zwischenbilder erzeugt werden. Die Schritte, die pro eingelesenem Eingangsbild ntig sind, um dieses Gleichgewicht aufrecht zu erhalten, werden als Operationszyklus bezeichnet. Diese Operationszyklen mssen fr jeden Modus ermittelt werden.

7.3.2 Interlaced Modus Operationen

7.3.2.1 Deinterlacing der halbbildkodierten Eingangsbilder


Die Zwischenzeilenfilter hat die Aufgabe, Halbbilder in Vollbilder umzuwandeln. Da der ASIC bei Luminanzdaten intern nur mit Vollbilddaten arbeitet, ist das Deinterlacing fr jedes Eingangsbild unumgnglich (siehe Tabelle 3). Die einzige Ausnahme bildet der 35

Anhang A: Handbuch fr den Simulator Movie Mode. Hierbei werden zwar Halbbilder eingelesen, jedoch bilden jeweils zwei Halbbilder ein Vollbild. Deshalb entfllt auch das Deinterlacing beim Movie Mode.

Tabelle 3: Zusammenfassende Spezifikation der Behandlung fr die Zwischenzeilengenerierung.

Bentigte Komponente Bedingung Bentigte Segmente

Zwischenzeilenfilter Fr jedes halbbildkodierte Eingangsbild. 1x(schreiben) die fehlenden Bildzeilen von Bild n (Luminanzanteil) als separates Halbzeilenbild. 1x(lesen) Luminanzanteil von Bild n. 1x(lesen) Top Luminanzanteil von Bild n-1. 1x(lesen) Bottom Luminanzanteil von Bild n-1. 1x(lesen) Top Luminanzanteil von Bild n+1. 1x(lesen) Bottom Luminanzanteil von Bild n+1. 1x(lesen) Blockvektoren von Bild n. Nicht vorhanden.

Rckgabewerte

7.3.2.2 Zwischenbildgenerierung fr Luminanzdaten


Der Zwischenbildfilter hat die Aufgabe, hochqualitative Zwischenbilder zu erzeugen. Vom Zwischenbildfilter werden die Luminanzanteile der zu generierenden Zwischenbilder erzeugt (siehe Tabelle 4). Die Einheit ist in der Lage, zwei Ausgabebilder gleichzeitig zu erzeugen unter der Einschrnkung, dass sich beide Ausgabebilder zeitlich vor oder hinter dem Sttzbild befinden (siehe Kapitel 6).

Tabelle 4: Zusammenfassende Spezifikation der Behandlung fr die Zwischenbildgenerierung bei halbbildkodierter Eingangsdaten.

Bentigte Komponente Bedingung Bentigte Segmente

Zwischenbildfilter Fr jeden Luminanzanteil des zu generierenden Ausgabebildes. 1x(schreiben) Ausgabebild Bild 1 (n,x1) (Luminanzanteil) 1x(schreiben) Ausgabebild Bild 2 (n,x2) (Luminanzanteil) (x1 und x2 mssen gleiche Vorzeichen haben, x2 kann 36

Stand der Technik entfallen) 1x(lesen) Top Luminanzanteil von Bild n. 1x(lesen) Bottom Luminanzanteil von Bild n. 1x(lesen) Top Luminanzanteil von Bild n-1 bei x1,x2<0 oder Top Luminanzanteil von Bild n+1 bei x1,x2>0. 1x(lesen) Bottom Luminanzanteil von Bild n-1 bei x1,x2<0 oder Bottom Luminanzanteil von Bild n+1 bei x1,x2>0. Rckgabewerte 1x(lesen) Blockvektoren von Bild n. Nicht vorhanden.

7.3.2.3 Zwischenbildgenerierung fr Chrominanzdaten


Bei den Chrominanzanteilen der zu generierenden Bilder wird die Zwischenzeileneinheit benutzt. Bei dieser Einheit wurde, um den ASIC homogen auszulasten, ein sekundrer Modus zur minderqualitativen Zwischenbildfilterung implementiert. Auch diese Einheit kann zwei Ausgabebilder gleichzeitig erzeugen mit der Einschrnkung das sich beide Ausgabebilder zeitlich vor oder hinter dem Sttzbild befinden (siehe Tabelle 5).

Tabelle 5: Zusammenfassende Spezifikation der Behandlung fr die Zwischenbildgenerierung fr Chrominanzdaten bei halbbildkodierter Eingangsdaten.

Bentigte Komponente Bedingung Bentigte Segmente

Zwischenzeilenfilter Fr jeden Chrominanzanteil des zu generierenden Ausgabebildes. 1x(schreiben) Ausgabebild Bild 1 (n,x1) (Chrominanzanteil) 1x(schreiben) Ausgabebild Bild 2 (n,x2) (Chrominanzanteil) (x1 und x2 mssen gleiche Vorzeichen haben, x2 kann entfallen) 1x(lesen) Chrominanzanteil von Bild n. 1x(lesen) Blockvektoren von Bild n. Nicht vorhanden. 37

Rckgabewerte

Anhang A: Handbuch fr den Simulator

7.3.2.4 Bildausgabe
Die Bildausgabe erfolgt mittels der Backend Einheit. Bei der Ausgabe kann eine Skalierung erfolgen (siehe Tabelle 6).

Tabelle 6: Zusammenfassende Spezifikation der Ausgabedatenbehandlung bei halbbildkodierter Eingangsdaten.

Bentigte Komponente Bedingung Bentigte Segmente

Backend Fr jedes Bild der Ausgabesequenz. 1x(lesen) Ausgabebild Bild (n,x) (Chrominanzanteil) 1x(lesen) Ausgabebild Bild (n,x) (Luminanzanteil) wenn (x 0) oder 1x(lesen) Top Luminanzanteil von Bild (n,x) und 1x(lesen) Bottom Luminanzanteil von Bild (n,x) wenn (x=0). Nicht vorhanden.

Rckgabewerte

7.3.3 Progressiv Modus Operationen

7.3.3.1 Zwischenbildgenerierung fr Luminanzdaten


Wird von der Zwischenbildfiltereinheit durchgefhrt. Die Einheit kann zwei Ausgabebilder gleichzeitig erzeugen mit der Einschrnkung, dass sich beide Ausgabebilder zeitlich vor oder hinter dem Sttzbild befinden (siehe Tabelle 7).

Tabelle 7: Zusammenfassende Spezifikation der Behandlung fr die Zwischenbildgenerierung fr Luminanzdaten bei vollbildkodierte Eingangsdaten.

Bentigte Komponente Bedingung Bentigte Segmente

Zwischenbildfilter Fr jeden Luminanzanteil des zu generierenden Ausgabebildes. 1x(schreiben) Ausgabebild Bild 1 (n,x1) (Luminanzanteil) 1x(schreiben) Ausgabebild Bild 2 (n,x2) (Luminanzanteil) 38

Stand der Technik (x1 und x2 mssen gleichen Vorzeichen haben, x2 kann entfallen) 1x(lesen) Luminanzanteil von Bild n. 1x(lesen) Luminanzanteil von Bild n-1 bei x1,x2<0 oder Luminanzanteil von Bild n+1 bei x1,x2>0. Rckgabewerte 1x(lesen) Blockvektoren von Bild n. Nicht vorhanden.

7.3.3.2 Zwischenbildgenerierung fr Chrominanzdaten


Die Zwischenbildgenerierung erfolgt nach dem in Kapitel 7.3.2.3. vorgestellten Verfahren (siehe Tabelle 8).

Tabelle 8: Spezifikation der Behandlung fr die Zwischenbildgenerierung fr Chrominanzdaten.

Bentigte Komponente Bedingung Bentigte Segmente

Zwischenzeilenfilter Fr jeden Chrominanzanteil des zu generierenden Ausgabebildes. 1x(schreiben) Ausgabebild Bild 1 (n,x1) (Chrominanzanteil) 1x(schreiben) Ausgabebild Bild 2 (n,x2) (Chrominanzanteil) (x1 und x2 mssen gleiche Vorzeichen haben, x2 kann entfallen) 1x(lesen) Chrominanzanteil von Bild n. 1x(lesen) Blockvektoren von Bild n. Nicht vorhanden.

Rckgabewerte

7.3.3.3 Bildausgabe
Die Bildausgabe erfolgt mittels der Backend Einheit. Bei der Ausgabe kann eine Skalierung erfolgen (siehe Tabelle 9). 39

Anhang A: Handbuch fr den Simulator

Tabelle 9: Spezifikation der Bildausgabe.

Bentigte Komponente Bedingung Bentigte Segmente Rckgabewerte

Backend Fr jedes Bild der Ausgabesequenz. 1x(lesen) Ausgabebild Bild (Chrominanzanteil) 1x(lesen) Ausgabebild Bild (Luminanzanteil) Nicht vorhanden.

40

Stand der Technik

8 Stand der Technik


Im folgenden werden Implementierungsalternativen zur Steuerung des HiCon Formatkonverters besprochen:

8.1 Die Entwicklung der Systemkontrolle in HDL


Die Mglichkeit, eine HDL fr die Realisierung der HiCon Systemkontrolle zu benutzen, ist durchaus in Betracht zu ziehen. Da alle anderen Komponenten von HiCon in VHDL beschrieben wurden. Somit wrde der vollstndige ASIC durchgehend homogen bezglich Sprachwahl und Entwurfkonzept sein. Dagegen sprechen jedoch folgende Punke:

8.1.1 Die Komplexitt des Steuermechanismus


Die Aufgaben, die diese Systemkontrolle zu bewerkstelligen hat, entsprechen, wenn man sie algorithmisch darstellt und aus der Sicht des HDL-Entwurfs betrachtet, einem Konzept von mehreren parallelen Zustandsmaschinen, welche die HiCon Komponenten parametrisieren sowie steuern. Diese werden von weiteren bergeordneten Zustandsmaschinen, die wiederum den Kernalgorithmus reprsentieren und somit den Zustand der gesamten Formatkonvertierung sowie den internen Zustand des ASICs abbilden, gesteuert und synchronisiert (siehe [1]). Somit wre es eine sehr schwierige Aufgabe, dieses Konzept flexibel zu modellieren und zu implementieren.

8.1.2 Die bentigte Chipflche


Bei einer HDL Lsung msste zwingender Maen der komplette Umfang, also ein Entwurf, der die Abwicklung aller mglichen Szenarien zulsst, in den ASIC fest

41

Anhang A: Handbuch fr den Simulator verdrahtet werden. Eine solche Lsung wrde eine Gatteranzahl beanspruchen, die sich mit der geplanten Gatteranzahl von HiCon nicht vereinbaren liee.

8.1.3 Sptere Austauschbarkeit und Freiraum fr Verbesserungen


Bei einer Hardware-Lsung fllt ferner negativ auf, dass kein Spielraum fr nderungen in Form einer nachtrglichen Integrationen neuer Modi vorhanden ist sowie dass das Verbessern vorhandener Modi nicht mglich ist. Solche Eingriffe wrden nur durch Entwurfsnderungen des ASICs mglich sein. Somit mssten alle Stadien der Entwicklung (wie z.B. Entwurf, Simulation, Synthese, Layout) erneut durchlaufen werden. Das entspricht einen langwierigen und kostenintensiven Vorgang. Gerade durch die architekturbedingte Flexibilitt von HiCon werden in Zukunft neue Anwendungen entstehen. Die Kosten fr eine solche nderung, die nur die Systemkontrolle betreffen wrde, machen diesen Kritikpunkt mit Sicherheit zum Schwerwiegendsten gegen die HDL-Lsung.

8.2 Die Systemkontrolle als Programm fr eingebettete Prozessoren


Als eine Alternative zu der HDL-Variante bietet es sich an, einen RISC-Prozessor in den HiCon ASIC zu integrieren. Dieser eingebettete Prozessor wre dann die Plattform, auf dem die Systemkontrolle als Programm implementiert werden wrde. Als eingebetteter Prozessor wurde der ARC-Prozessor von Argonaut Systems (siehe [7]) schon mehrmals erfolgreich beim Heinrich-Hertz-Institut in verschiedene ASICs integriert, so dass dieser Prozessor von der Projektleitung vorgegeben wurde. Dieser Ansatz zur Realisierung der Systemkontrolle bringt wieder Vor- und Nachteile. Als Nachteil knnen diese Punkte aufgefhrt werden:

42

Stand der Technik

8.2.1 Nachteile der Software-Lsung


8.2.1.1 Abarbeitungsgeschwindigkeit
Der ARC-Prozessor ist von seiner Architektur her ein einfacher 32-Bit-RISC-Prozessor (siehe [5]). Er hat daher nicht die Leistungsdaten eines modernen Prozessors. Unabhngig davon ist zu bercksichtigen, dass ein Programm, das von einem Prozessor ausgefhrt wird bei gleicher Taktung niemals die Geschwindigkeit erreichen kann, die eine in HDL speziell fr ein Problem entworfene und optimierte Schaltung erreicht. Die Arbeiten, welche die Systemkontrolle zu verrichten hat, haben einen Aufwand der gegen eine Prozessor-Lsung spricht. Eventuell sind sptere Optimierungen hinsichtlich Programmgeschwindigkeit und -Gre ntig.

8.2.1.2 Anstieg der Leistungsaufnahme des ASICs


Ein Prozessor ist stndig in Betrieb. Auch wenn der ASIC keine Sequenzen konvertiert, muss der Prozessor in NOP-Schleifen iterieren. Eine bergeordnete Kontrollschaltung die den Prozessor aktiviert bzw. deaktiviert, knnte Abhilfe schaffen. Diese ist aber in dem Konzept des ASICs noch nicht vorgesehen. Die durchschnittliche Leistungsaufnahme des Prozessors sowie seiner Peripherie wrde sich dadurch erhhen.

8.2.1.3 Zunahme der externen Komponenten


Gegenber der HDL-Variante braucht die Prozessor-Variante der Systemkontrolle zustzliche externe Komponenten. Dazu gehren ein Festspeicher (z.B. EEPROM) fr die Speicherung des Programms zur Systemkontrolle, sowie RAM als Arbeitsspeicher fr den Prozessor.

43

Anhang A: Handbuch fr den Simulator

8.2.2 Vorteile der Software-Lsung


8.2.2.1 Krzere Entwicklungszeiten
Programmiersprachen stellen ein mchtigeres Werkzeug zur Komplexittsbewltigung als HDL-Sprachen dar, da ein hheres Abstraktionsniveau bei der Entwicklung vorliegt.

8.2.2.2 Einsparungen bei der Chipflche


Bei einer Software-Lsung befinden sich das Programm sowie der Arbeitsspeicher, auerhalb des ASIC, somit beansprucht nur der kompakte, eingebettete Prozessor Chipflche.

8.2.2.3 Austauschbarkeit und Verbesserbarkeit der Systemsteuerung


Der Inhalt des Festspeichers kann jederzeit durch ein erweitertes oder verbessertes Programm ersetzt werden. Hierfr sind keine nderungen im ASIC ntig.

8.2.2.4 Benutzerspezifische Varianten


Es ist ferner mglich fr den Benutzer zugeschnittene Varianten des Konverters zu liefern, die nur die ntigen Modi des Steuerprogramms beinhalten. Somit kann die Gre des RAMs sowie des Festspeichers noch weiter reduziert werden.

8.3 Die Klassifizierung der Plattform zur Systemsteuerung


Die Software-Variante der Systemsteuerung mit Hilfe eines eingebetteten Prozessors ist der in HDL entworfenen Systemsteuerung vorzuziehen. Die Software-Variante hat die entscheidenden Vorzge der schnellen Implementierung, der einfachen Erweiterbarkeit sowie Austauschbarkeit. Der entscheidende Nachteil der langsameren Abarbeitungsgeschwindigkeit ist im Vergleich mit den Nachteilen einer HDL-Lsung

44

Stand der Technik vertretbar. Der erzielte Zeitgewinn bei der Implementierung kann fr Optimierungsarbeiten investiert werden kann.

8.4 Die Wahl der Programmiersprache fr die Implementierung


Um die Frage nach der am besten geeigneten Programmiersprache fr die Implementierung zu beantworten, muss eine Liste der Anforderungen an diese Programmiersprache erstellt werden. Danach werden wir die mglichen Kandidaten nach deren Eignung untersuchen.

Eine Sprache mit einem gut optimierenden bersetzer


Sprachen, die nur einen Interpreter anbieten, sind fr Steuerungszwecke zu langsam. Der bersetzer soll nach Mglichkeit kompakten und gut optimierten Kode erzeugen.

Eine Sprache, die hardwarenahe Programmierung untersttzt


Die Sprache muss es zulassen, Hardware direkt anzusprechen und zu manipulieren.

Untersttzung von Assemblerintegration


Es steht fest, dass Programm nicht von Begin an in Maschinensprache oder Assembler zu Implementieren. Dies wrde durch das Fehlen von komplexen Datentypen sowie Sprachkonstrukten eine lngere Zeit in Anspruch nehmen. Stattdessen werden die Programmroutinen, die eine Optimierung bentigen, durch Assemblerroutinen ausgetauscht. In der Praxis wird dieser Weg wegen des Zeitgewinns bei der Implementierung hufig praktiziert. Nur kleine und extrem zeitkritische Programme werden direkt in Assembler geschrieben. Unter Beachtung dieser drei Aspekte scheiden Sprachkategorien der logischen Programmiersprachen (z.B. PROLOG) sowie der funktionalen Programmiersprachen (z.B. GOFER) direkt aus. Sie erfllen keine der drei Anforderungen. Imperative Programmiersprachen eignen sich hervorragend fr die Systemprogrammierung, weil 45

Anhang A: Handbuch fr den Simulator die Sprache dem Verhalten des Prozessors nachempfunden ist. Es gibt eine Vielzahl von bersetzern (Compiler) fr diese Sprachgattung. Bei den imperativen Programmiersprachen muss zwischen objektorientiert und strukturiert unterschieden werden. Objektorientierte Sprachen eignen sich hervorragend fr die Komplexittsbewltigung. Jedoch bieten objektorientierte Konzepte fr Systemprogrammierungsaufgaben keinen bedeutenden Vorteil. Diese Mechanismen zahlen sich, wegen des entstehenden Overheads, erst fr grere Projekte aus. Entscheidende Nachteile sind die langsamere Ausfhrungsgeschwindigkeit sowie der nach der bersetzung entstehende grere Programmkode. Die Grnde hierfr sind technischer Natur: Sprachkonzepte wie Polymorphie, berladung und Vererbung werden von dem bersetzer in Datenstrukturen wie z.B. Hashtabellen, Bume oder Graphen berfhrt, um z.B. bei Laufzeit zu entschlsseln, welche konkrete Methode bei einem Aufruf gemeint ist. Dadurch wird der Kode fr Programme bei identischer Funktionalitt grer. Whrend der Laufzeit mssen diese Datenstrukturen traversiert werden, diese Praxis wird mit einem Geschwindigkeitsverlust bei der Ausfhrung erkauft. Aus der Gruppe der strukturierten iterativen Sprachen gibt es eine Vielzahl von Vertretern. Bei der hardwarenahen Programmierung hat sich jedoch die Sprache C (siehe [2]) seit ca. 30 Jahren als beste Alternative bewhrt. Fr den ARC Prozessor existiert von Metaware ein C-bersetzerpaket mit dem Name High C/C++ (siehe [8]). Der bersetzer von High C/C++ verfgt ber Optimierungsstrategien, die speziell fr die RISC Architektur des ARC Prozessors ausgelegt sind. Ferner ist eine nahtlose Assemblerintegration mglich. Die Sprache ist weitgehend ANSI-C konform, wobei die Untersttzung fr ARC-spezifischen Funktionen von ANSI-C abweicht. Die Eigenschaften der Sprache C und speziell des High C/C++ bersetzers, welche die Anforderungen vollends erfllen, machen sie fr die Implementierung erste Wahl.

8.5 Verifizierungsstrategien
Da HiCon zur Zeit noch in der Entwicklung ist, muss, um die Korrektheit der Steuerung zu gewhrleisten, ein Konzept erarbeitet werden, womit die Systemkontrolle verifiziert werden kann. Die Verifikation der Systemkontrolle kann durch einen speziell dafr 46

Stand der Technik entwickelten Simulator geschehen. Dieser Simulator muss in der Lage sein, die Komponenten von HiCon hinreichend zu ersetzen und den Benutzer ber die verschiedenen Ablufe im Programm zu informieren. Fr den Simulator fr die Systemsteuerung ist als Operationsplattform Microsofts Windows 32Bit bedacht. Um ein Windows Programm mit einer graphischer Benutzeroberflche zu implementieren, eignet sich Visual Studio C++ am besten. Die API Bibliotheken moderner Betriebsysteme sind fr objektorientierte Programmiersprachen ausgelegt. Die Wahl der Sprache C++ (siehe [3]) fr den Simulator erlaubt zudem noch eine ausgesprochen gute Integration der Systemkontrolle, da C mit kleineren Einschrnkungen eine Untermenge von C++ darstellt.

47

Anhang A: Handbuch fr den Simulator

8.6 Zusammenfassende Klassifizierung


Systemkontrolle: Technische Basis: Programm, das auf einem in HiCon integrierten eingebetteten Prozessor luft. Der Prozessor verfgt ber einen externen Speicher. Das Programm wird in einem EEPROM gespeichert. Programmiersprache: High C/C++ von Metaware (nur C Anteil wird benutzt). Simulator: Konzept: Mit graphischer Benutzeroberflche unter 32 Bit Windows laufend. Programmiersprache: Microsoft Visual C++

48

Stand der Technik

9 Implementierung
Hier werden die Hauptrichtlinien bei der Implementierung der Systemkontrolle von HiCon erlutert. Die Einschrnkungen des Systems tragen dazu bei, die Strategie fr die Implementierung der HiCon Systemkontrolle fr die verschiedenen Modi zu bestimmen.

9.1 berlegungen bezglich Speicherausnutzung sowie Performanz des Programms

9.1.1 Bibliothekenbenutzung
Externe Bibliotheken bieten Lsungen fr Probleme, die bei der Programmierung entstehen. Sie werden angeboten, weil sie die Implementierung eines Programms erheblich beschleunigen, indem sie vorgefertigte Lsungen fr Probleme bieten, die bei der Implementierung verschiedener Anwendungen entstehen. Wegen des generischen Funktions- und Leistungsumfanges, den sie bieten, sind sie aber stets umfangreicher als Lsungen, die speziell fr die beschrnkte Untermenge des Problems entworfen worden sind. Infolge des limitierten Arbeitsspeichers und des kritischen Laufzeitverhaltens wird auf externe Bibliotheken verzichtet. Stattdessen werden alle bentigten Routinen fr die Systemkontrolle von Hand entworfen.

9.1.2 Benutzung von Threads


Der Mangel an Arbeitsspeicher fhrt zu der berlegung, keine Threads zu benutzen. Es gibt hierfr mehrere Grnde: Als erstes wird die Threads Untersttzung bei der Sprache C in Form von externen Bibliotheken angeboten. Dadurch wrde die Prmisse, keine Bibliotheken zu benutzen, verletzt werden. Ferner haben Threadumgebungen den 49

Anhang A: Handbuch fr den Simulator entscheidenden Nachteil, dass jeder Thread von der Laufzeitumgebung des bersetzers seinen eigenen Laufzeitspeicher in Form von Stack- und Heapspeicher zugewiesen bekommt. Somit wchst der Bedarf an Speicherressourcen des Programms zur Laufzeit erheblich. Threads wren fr die HiCon Systemkontrolle jedoch durchaus sinnvoll, aus diesem Grund wird eine Methode entwickelt, die den Threads nahe kommt. Diese Methode wird in Form von quasiparallel arbeitenden Zustandsmaschinen realisiert. Die Implementierung dieser Zustandsmaschinen wird im nchsten Abschnitt erlutert.

9.1.3 Dynamische Speicherverwaltung


Dynamische Speicherverwaltung bringt Freiheiten fr den Programmierer. Das Programm alloziert Speicher bei Bedarf von der Laufzeitumgebung, um z.B. Datenstrukturen zu erzeugen und gibt diesen Speicher anschlieend wieder frei, falls der Speicher nicht mehr gebraucht wird. Der Speicher wird von der Laufzeitumgebung des bersetzers in Form eines Speicherpools verwaltet. Dieser Mechanismus kann dafr benutzt werden, um z.B. Queues zu implementieren, die beliebig viele Elemente enthalten knnen. Diese Arten von Datenstrukturen werden in der Regel in Form von verketteten Listen mit Hilfe von Zeigervariablen realisiert. Die Nachteile sind der entstehende zustzlicher Speicher fr die Hilfsdatenstrukturen und der Performanznachteil wegen der Funktionsaufrufe fr die Freispeicherverwaltung. Die Funktionen zur Freispeicherverwaltung stehen zudem in externen Bibliotheken. Als letzter Nachteil ist die stndige Zu- bzw. Abnahme der gesamten Programmgre zur Laufzeit zu nennen. Als Folge dieser berlegung wird der bentigte Speicher fr die Datenstrukturen der Systemkontrolle vorberechnet und statisch und global instanziiert.

50

Stand der Technik

9.2 Implementierungsstrategien

9.2.1 Das Konzept der quasiparallel arbeitenden Zustandsmaschinen als Substitut fr Threads
Die Systemsteuerung von HiCon hat unter anderem die Aufgabe, die verschiedenen Hardwarekomponenten des Systems zu steuern. Die Steuerung der Komponenten (oder Einheiten) besteht aus dem Starten, Anhalten und Parametrisieren dieser Komponenten ber die PU-Schnittstelle. Wenn nun eine Einheit ihre letzte Aufgabe erfllt hat, mssen Daten ber die PU eingelesen werden. Danach erfolgt die Berechnung der neuen Parameter fr den nchsten Lauf. Als nchstes werden die Parameter zu der Einheit bertragen. Als letztes wird die Einheit gestartet. Dieser Ablauf ist zeitkritisch und muss daher so schnell wie mglich erfolgen. Betrachtet man aber nun den Umstand, das HiCon mehrere Einheiten hat, die den oben genannten Zyklus, teilweise mit kleineren nderungen, verlangen, welche durchaus zu gleichen oder aber auch verschiedenen Zeitpunkten behandelt werden mssen, kommt man zu der Folgerung: Die Einheiten mssen voneinander unabhngig, also parallel zueinander, gesteuert werden. Auf einem sequenziellen Prozessor ist echte parallele Abarbeitung mehrerer Instruktionsfolgen jedoch nicht realisierbar. Es gengt aber eine quasiparallele Abarbeitung mehrerer Programmteile in Zeitscheiben. Diese Quasiparallelitt wird von Threadumgebungen eingehalten. Wegen des Verzichts auf Threads muss hierfr eine andere Programmiertechnik speziell fr die HiCon Steuerung entwickelt werden. Um einen Steuerungsmechanismus zu entwerfen, der dieses Verhalten widerspiegelt, mssen Funktionen implementiert werden, die die Steuerung einer Einheit bernehmen. Eine solche Funktion hat bei seinem Aufruf einen Teil ihrer Gesamtfunktion abzuarbeiten, um dann die Kontrolle an die aufrufende Funktion zurckzugeben. Damit wrde das Programm nacheinander die jeweiligen Funktionen fr die Steuerung der verschiedenen Einheiten aufrufen, die Kontrolle aber nach der Abarbeitung einer 51

Anhang A: Handbuch fr den Simulator Teilinstruktionskette an das Programm zurckgeben. Aus der Sicht des Betrachters werden diese Funktionen somit nebeneinander ausgefhrt. Abbildung 31 stellt eine exemplarische Zustandsmaschine dar, die in einer imperativen Programmiersprache zu implementieren ist. Bei dem angegebenen Algorithmus in Psydokode (siehe Abbildung 32) wird ersichtlich, dass die Prozedur zustandsmaschine stndig aufgerufen werden muss. Bei jedem Aufruf kann hchstens eine Transition schalten und somit eine Zustandsnderung erfolgen.

u A A

s t a n n w w

n e e

_ is u is u

1 n n g g _ 1 _B 2 e d in g u n g _ 2

is u B e

n d

g in

n g u n g _ 1 Z u s t a n d A A n n w w e e

2 n n g g _ _ 1 2

is u is u

in

is u

Z A A

s t a n n w w e e

3 n n g g _ _ 1 2

in

is u is u

is u

Abbildung 31: Schematische Darstellung einer quasiparallelen Zustandsmaschine.

52

Stand der Technik

procedure zustandsmaschine(zustand z) begin: if(z=Zustand1) then Anweisung_1; Anweisung_2; Anweisung_N; if(Bedingung_1) then z:=zustand2 endif; return; else if(z=Zustand2) then Anweisung_1; Anweisung_2; Anweisung_n; if(Bedingung_2) then z:=Zustand_1 endif; if(Bedingung_3) then z:=Zustand_3 endif; return; else if(z=Zustand_3) then Anweisung_1; Anweisung_2; Anweisung_n; if(Bedingung_4) then z:=Zustand_1 endif; return; end if; end zustandsmaschine;

Abbildung 32: Quelltext einer quasiparallelen Zustandsmaschine.

53

Anhang A: Handbuch fr den Simulator Mit diesem Konzept knnen mehrere parallele Zustandsmaschinen und eine hierarchische Verschachtelung von Zustandsmaschinen implementiert werden. Die Synchronisierung von Zustandsmaschinen erfolgt durch globale Variablen.
Z u A A B e d i n g u A Z u A A s t a n n w w n e e d 2 n n g g B n s t a n n g n w w w 4 e is u n g n n e e d 1 n n g g 1 B2 e d i n g u n g 1

is u is u

B 1 2 e

i n

u Zn

u g A A

s 2t a n n 3 w w

n e e

3 n n g g 1 2

i s u i s u

is u is u

i n

i s u

is u

u A A

s t a n n w w

n e e

_ n n T

1 g g R g m 1 2 U E

u A

s t a n w

n e

_ 2 n g m

is u is u

i s u

is u

i s u

Abbildung 33: Verfeinerung der Zustnde.

Falls eine zu einem Zustand gehrende Anweisungsfolge zu viel Zeit beansprucht, so dass infolgedessen andere zeitkritische Anweisungsfolgen beeintrchtigt werden, kann diese Anweisungsfolge, wie in Abbildung 33 illustriert, in mehrere Anweisungsfolgen 54

Stand der Technik aufgebrochen werden. Es mssen dann fr alle neuen Anweisungsfolgen neue Zustnde definiert werden. Diese Zustnde werden dann durch Transitionen so verschaltet, dass die Semantik der Anweisungsfolge nicht verflscht wird.

9.2.2 Systemtiming
Unter Systemtiming wird der zeitliche Ablauf bei der Formatkonvertierung in dem ASIC bezeichnet. Systemtimingdiagramme sind wichtig, um die verschiedenen Aufgaben der Komponenten im Gesamtkontext der Wandlung sowie die zeitlichen Ablufe zu betrachten. Diese Diagramme geben Auskunft darber, welche Daten zu einem bestimmten Zeitpunkt im Datenspeicher existieren mssen. Wenn sich bei einer Komponente zwei Aufgaben zeitlich berschneiden, werden sie nacheinander ausgefhrt. Dabei werden Aufgaben, die frher anfangen, begnstigt. Falls jedoch zwei Aufgaben an exakt dem selben Zeitpunkt anliegen, werden die Aufgaben priorisiert, die auf lteren Bilddaten operieren. Die Bildgenerierungsoperationen werden zusammengefasst notiert. Dabei werden diese Operationen in Abhngigkeit vom Wandlungsverhltnis verschieden viele Zwischenbilder generieren. Daher knnen abhngig vom Wandlungsverhltnis fr jede eingetragene Bildgenerierungsoperation mehrere Durchlufe mit den Komponenten ntig sein. Die Lnge der Symbole, die die Operationen reprsentieren, ist dabei nicht als exakte Dauer der Laufzeit zu deuten. Wegen des Buskonzeptes des ASIC knnen identische Operationen unterschiedlich lange Zeiten beanspruchen. Im folgenden werden verschiedene Systemtimingdiagramme fr die unterschiedlichen Modi aufgefhrt. Abbildung 34 gibt Auskunft ber die dabei verwendete Notation.
B
C

e m
h r o m

L u m

i n a n z d a t e n i n

e r k u F n ( gN e - 2n ) : + A l l

e p o s i t i v e n f r g e g e b e n e

F PB (oi N s d i - t u2i on ) n gn

e n

( N
D

- 2 )

a n z d a t e n B i n d u n g

A l l e n e g a t i v e n P o s i t i o n e n B i l d g e n e r i e r uf n r g g e g e b e n e B i n d u n g e i n t e r l a c i n g

Abbildung 34: Erklrung der benutzten Notation bei den Timingdiagrammen.

55

Anhang A: Handbuch fr den Simulator

9.2.2.1 Vollbildmodus
Der Vollbildmodus beinhaltet keine Halbbild/Vollbildwandlung. Die Laufzeiten der Filterkomponenten knnen aber lnger sein als bei dem Halbbildmodus (siehe Abbildung 35).

Z F r o

T it n t e

0 n
N N

T d

1
N N + 1 + 1

2
N N N + 2 + 2 + 1 )

3
N N N + 3 + 3 + 2

4
N N N + 4 + 4 + 3

5
N N N + 5 + 5 + 4

6
N N N + 6 + 6 + 5 + 4 )

B e w e g u n g N s c h t z u -n 1 g Z w i s c h e F ( -N n z e i l e n f i lt e r
F ( N

s N

- 1 ) F ( N

F ( N

+ 1 F) ( N

+ 2F) ( N

+ 3 F ( N )

- 1 ) -F

( N

) -

F ( N

+ 1 F) - ( N

+ 2 F ) (- N

+ 3 )F - ( N

+ 4 ) -

Z w i s c h b il d f il t e

e r

F ( N - 1 ) F+ ( N N N ) + F ( N N N N N + + + 1 ) + F ( N + 3 F +( N ) + 4 ) +

c k e

Abbildung 35: Systemtiming bei Vollbildmodus.

Die folgende Abbildung 36 illustriert die Datenabhngigkeiten bei diesem Modus. Dabei werden fr die Operationen, auf die die Pfeilspitzen zeigen, die Resultate der Operationen, von denen die Pfeile ausgehen, bentigt.

56

Stand der Technik

Z F r o

e n

it t e n
N N

N N

+ 1 + 1 N F ( N

N N

+ 2 + 2 + 1 ) F ( N

N N

+ 3 + 3 N + 1 )

N N

+ 4 + 4 + 3 N

N N

+ 5 + 5 + 4

N N

+ 6 + 6

B e w e g u n g s c h t z u n g Z w i s c h e n z e i l e n f i lt e r Z b i s c h il d f il t e w e r n -

s N

F ( N

) -

F ( N

+ 3 ) -

F ( N N N

) + N N N N + +

F ( N

+ 4 ) +

c k e

n d

Abbildung 36: Datenabhngigkeiten beim Vollbildmodus.

Die in schwarzer Farbe gezeichnete Pfeile symbolisieren Luminanzdaten. Die grauen Pfeile stellen Chrominanzdaten dar.

9.2.2.2 Halbbildmodus
Der Halbbildmodus fllt durch die Halbbild/Vollbild Wandlung der eingehenden Luminanzdaten auf. Dabei ist zu beachten, dass der Zwischenzeilenfilter zwei unterschiedliche Operationstypen untersttzen muss, und somit auf Luminanz- sowie Chrominanzdaten operiert (siehe Abbildung 37).

57

Anhang A: Handbuch fr den Simulator

Z F r o

e n

T it t e

0 n
N N

T d

1
N N + 1 + 1

2
N N N + 2 + 2 + 1 ) ( N

3
N N N + 3 + 3 + 2

4
N N N + 4 + 4 + 3

5
N N N + 5 + 5 + 4

6
N N N + 6 + 6 + 5 + 4 )

B e w e g u n g N s c h t z u -n 1 g Z w i s c h e Fn ( -N z e i l e n f i lt e r
D ( N - 2 )D

s N

- 1 ) F ( N ( N - 1 )D

F ( N ) D

+ 1 F) ( N ( N

+ 2 F ( N )

+ 3 )F ( N

+ 1D ) ( N

+ 2 D) ( N

+ 3 D) ( N

+ 4 )

Z b

i s c h e il d f il t e r

F ( N

- 2 ) F- ( N - 3 ) F+ ( N

- 1 ) -F ( N - 2 ) F+ ( N

) - 1 ) +F ( N ( N ( N

F ( N ) +F ( N

+ 2 )F - ( N + 1 ) + + ) + )

+ 3 ) -

F ( N

c k e

n d

, P( N - ) , ( 0 N ) , P , P( N - ) , ( 0 N ) , P

Abbildung 37: Systemtiming fr Halbbildmodus.

In Abbildung 38 werden wieder die Datenabhngigkeiten dargestellt.

58

Stand der Technik

r o

n t e

N N

N N

+ 1 + 1 N ( N

N N

+ 2 + 2 + 1 ) ( N F ) N ( N D

N N

+ 3 + 3 + 2 N

N N

+ 4 + 4 + 3 N ( N

N N

+ 5 + 5 + 4 + 3 F ) N ( N

N N

+ 6 + 6 + 5 + 4 ) + 4 )

B e w e g u n g s c h t z uN -n 1 g Z w i s c h e F ( -N n z e i l e n f i lt e r
D ( N - 2 )D

s N

- 1 ) F ( N

+ 1 F) ( N ( N

+ 2 F)

- 1 )D

+ 1D ) ( N

+ 2 D) ( N

+ 3 D) ( N

Z b

i s c h il d f il t e

e r

F ( N

- 2 )F- ( N - 3 )F+ ( N

- 1 ) -F ( N - 2 ) F+ ( N

) - 1 ) + F ( N ( N ( N

F ( N ) +F ( N

+ 2 )F - ( N + 1 ) + + ) + )

+ 3 ) -

F ( N

c k e

n d

, P( N - ) , ( 0 N ) , P , P( N - ) , ( 0 N ) , P

Abbildung 38: Datenabhngigkeiten beim Halbbildmodus.

59

Anhang A: Handbuch fr den Simulator

9.2.3 Partitionierung des HiCon Datenspeichers


Tabelle 10: Die von Modus abhngige Aufteilung des Speichers in Speichersegmente und die Belegung der einzelnen Segmente. HALBBILDMODUS
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

VOLLBILDMODUS
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

Luminanzdaten ( 6 Halbbild) Chrominanzdaten Eingangsbilder ( 6 Halbbild) Quincunxbilder ( 4x) Nonquincunx ( 4x) Bewegungsschtzung Bewegungsvektoren ( 4 ) Luminanzdaten Zwischenzeilenfilter ( 4 Halbbild) Chrominanzdaten ( 6 Halbbild) Zwischenbildfilter Luminanzdaten ( 4 Vollbild)

Luminanzdaten ( 5 Vollbild) Chrominanzdaten Eingangsbilder ( 5 Vollbild) Quincunxbilder ( 4 ) Nonquincunxbilder ( 4 ) Bewegungsschtzung Zwischenzeilenfilter Zwischenbildfilter Bewegungsvektoren( 3x) Chrominanzdaten ( 4 Vollbild) Luminanzdaten ( 4 Vollbild)

Audiodaten

Audiodaten

Audiodaten

Audiodaten

60

Stand der Technik Durch die Systemtimingdiagramme wird die Speicherpartitionierung der verschiedenen Modi ersichtlich. Um die Speicherpartitionierung fr einen bestimmten Modus herzuleiten, sollte die gesamte Anzahl der in der Pipeline befindlichen Bilder und die zum Erzeugen dieser Bilder ntigen weiteren Bilder und Vektoren notiert werden. Diese Bilder sind dann nach Typen zu kategorisieren. Anschlieend werden fr jeden Bildtyp so viele Segmente erstellt, wie sie zu einem Zeitpunkt t im Systemtimingdiagramm auftauchen (siehe Tabelle 10).

9.2.4 Abbildung des HiCon Datenspeichers


Wie schon in den frheren Kapiteln erwhnt, ist es fr die Systemprogrammierung wichtig, ein Abbild der Segmentierung und Belegung des HiCon Datenspeichers zu errichten. Diese Abbildung knnte durch Datenstrukturen erfolgen. Es ist weiterhin vorteilhaft, wenn die Datenstrukturen eine von den Formatkonvertierungsalgorithmen benutzbare Notation enthalten. Somit werden keine redundanten Datenstrukturen entstehen, womit das Programm von der Laufzeitgre her kompakter wird und unter dem Aspekt der Zugriffe auf die Datenstrukturen auch schneller ausgefhrt wird. Die im Kapitel 6 vorgestellte 2-Tupel Notation fr Bilder anhand von Bindungsbereich und Position sollte fr die Belegung der Segmente benutzt werden. In den Tabellen 11 bis 13 werden die Datentypen fr die verschiedenen Segmente aufgefhrt. Neben den fr die spezifischen Segmente wichtigen Informationen, wie z.B. fr Segmente mit Eingangsbildern Information darber ob das Bild Top oder Bottom Field ist, werden weiterhin folgende gemeinsame Merkmale notiert: write: Ob das Bild gerade erstellt wird. uid: Von welcher Einheit das Bild gerade bearbeitet wird. Diese Information ist nur dann relevant wenn write = TRUE ist. mask: Ob das Segment belegt ist. mid: Bindung des Bildes. sid: Position des Bildes. sid Wird nur bei generierten Bilder aufgefhrt, da es sonst immer gleich Null ist.

61

Anhang A: Handbuch fr den Simulator Tabelle 14 hingegen stellt die in Tabelle 10 dargestellte Speicherpartitionierung fr den Halbbildmodus dar. In der Datenstruktur memory_mapper tauchen die in Tabelle 11 bis 13 vorgestellten Datenstrukturen fr verschiedene Segmente jeweils in Form von Arrays auf. Die verschiedenen Arrays haben so viele Elemente wie Segmente des Bildtyps existieren. Da die Arrays durch Konstanten instanziiert werden, ist die Anzahl der Segmente fr einen Bildtyp jederzeit komfortabel nderbar. Ferner existieren sogenannte Indexkonstanten fr die Segmenttypen. Damit kann die Reihenfolge der Segmentblcke jederzeit problemlos umkonfiguriert werden. Die Indexkonstanten werden auf die Elementnummer des Segmentarrays addiert. Diese Operation liefert dann die korrekte Segmentadresse fr den Speicherkontroller. Um zum Beispiel Speicher fr einkommende Bilder zu alloziieren iteriert die Systemkontrolle mit einer fornext Anweisung die in Frage kommenden Segmente und berprft anhand der Belegungsmaske (mask), ob Segmente zur Verfgung stehen.
for(loop=0;loop<IN_LUM;loop++) { if(!g_memory_map.il[loop].mask) { found++; g_unit_mem_slots.fe_lum_slot = loop; break; } }

Danach wird dem Speicherkontroller mit Hilfe der Parametereinheit mitgeteilt, welche Einheit auf diesem Segment operieren soll. Bei dem Beispielszenario ist dies die Frontend Einheit. Anschlieend wird die Frontend Einheit, sofern sie nicht beschftigt ist, parametrisiert und gestartet. Das Parametrisieren und Starten erfolgt wieder ber die Parametereinheit. Wenn die Frontend Einheit nach dem Start terminiert, liegt das gewnschte Eingangsbild in diesem Segment. Das Freigeben der Segmente bentigt keine weitere Kommunikation mit dem Speicherkontroller. Sie erfolgt mit dem Suchen des Segments, welche die mid und sid der zu lschenden Bilder enthlt. Nach dem erfolgreichen Lokalisieren des Segments wird die Belegungsmaske auf frei gesetzt. Ferner kann jederzeit anhand von mid, sid und mask der Inhalt des Speichers von Formatkonvertierungsroutinen konsultiert werden, um z.B. Auskunft zu erhalten, ob die Bedingungen fr einen Formatkonvertierungsschritt erfllt sind.

62

Stand der Technik


Tabelle 11: Datenstruktur fr ein Segment der Eingangsbilder.

/* structure for memory mapping on input data */ struct mem_entry_input{ /* main id */ unsigned char mid; /* usage mask */ unsigned char mask:1; /* under work bit */ unsigned char write:1; /* unit id of involved unit */ unsigned char uid:3; /* top/bottom indicator */ unsigned char top:1; /* movie mode pic indicator*/ unsigned char mm:1; /* movie mode phase bit */ unsigned char phase:1; };

/* structure for memory mapping on intermediate data */ struct mem_entry_temp{ /* main id */ unsigned char mid; /* usage mask */ unsigned char mask:1; /* under work bit */ unsigned char write:1; /* unit id of involved unit */ unsigned char uid:3; };

Tabelle 12: Datenstruktur fr ein Segment der Zwischengren (z.B. Vektoren).

Tabelle 13: Datenstruktur fr generierte Bilder. Erfasst einen Segment.

/* structure for memory mapping on generated output data */ struct mem_entry_generated{ /* main id */ unsigned char mid; /* sub id */ signed char sid; /* usage mask */ unsigned char mask:1; /* under work bit */ unsigned char write:1; /* unit id of involved unit */ unsigned char uid:3; };

/* structure representing the hicon picture memory */ struct memory_mapper{ /* arrays containing the mapping of slots */ struct mem_entry_input il[IN_LUM]; struct mem_entry_input ic[IN_CHR]; struct mem_entry_temp qu[QUINN]; struct mem_entry_temp nq[N_QUINN]; struct mem_entry_temp ve[VECS]; struct mem_entry_temp dl[DI_LUM]; struct mem_entry_generated gc[FG_CHR]; struct mem_entry_generated gl[FG_LUM]; } g_memory_map;
Tabelle 14: Datenstruktur fr Halbbildmodus Speicherabbildung.

63

Anhang A: Handbuch fr den Simulator

9.2.5 Operationen auf Erweiterungsregister


Die Operationen auf die Erweiterungsregister des ARC-Prozessors sind von essentieller Wichtigkeit fr die Kommunikation der Systemkontrolle mit dem ASIC-Kern. Da die Kommunikation zwischen der Systemkontrolle und den HiCon Komponenten mittels der Parametereinheit erfolgt und da ferner die Kommunikation mit der Parametereinheit nur ber Register und Unterbrechungssignale erfolgt, mssen zahlreiche Lese- und Schreibzugriffe auf die Register erfolgen. Die Implementierung der Programmiersprache C in dem Metaware High C/C++ bersetzerpaket lsst jedoch keinen Zugriff auf diese Register in C zu. Deshalb mssen Lese- und Schreibeoperationen auf Register durch Funktionen in Inline Assembler Notation erfolgen. An verschiedenen Stellen des Programms werden diese Assemblerroutinen wie native C-Routinen aufgerufen. Dadurch mssen auch die Funktionsparameter in C-Notation berreicht werden. Die Maschinensprache des ARC-Prozessors unterscheidet jedoch zwischen konstanten Ausdrcken (Direktspeicherzugriff) und variablen Ausdrcken (Registerzugriff), so dass fr beide Szenarien differenzierter Kode programmiert werden muss, da bei C Funktionen mit konstanten sowie variablen Gren parametrisiert werden knnen (siehe Beispielkode).
_Asm eineFunktion(int wert1, int wert2) { /* beide Werte als Register */ % reg wert1, wert2 Behandlungskode mit Assembleranweisungen /* Wert1 Register/Wert2 Konstante */ % reg wert1; con wert2 Behandlungskode mit Assembleranweisungen /* Wert1 Konstante /Wert2 Register */ % con wert1; reg wert2 Behandlungskode mit Assembleranweisungen /* beide Werte als Konstante */ % con wert1, wert2 Behandlungskode mit Assembleranweisungen }

64

Stand der Technik

9.2.6 Unterbrechungsroutinen
Unterbrechungsroutinen werden benutzt, um die von der Parametereinheit kommenden Unterbrechungssignale auszuwerten. Die Kommunikation mit der Auenwelt ber ein I2C-Protokoll erfolgt unterbrechungsgesteuert. Die Parametereinheit erzeugt ferner Unterbrechungssignale fr terminierende HiCon Komponenten. Da bei ARCProzessoren architekturbedingt Unterbrechungen, die eintreffen whrend eine Unterbrechung behandelt wird, verloren gehen, wurden die separaten Unterbrechungssignale zu einem gemeinsamen Unterbrechungssignal zusammengefasst. Wenn dieses Signal eine Unterbrechung auslst, muss in der aufgerufenen Unterbrechungsroutine anhand der Statusregister der Parametereinheit ausgewertet werden, um welche Einheit es sich konkret handelt. Es ist auch weiterhin wichtig, die Unterbrechungsroutine so klein und kompakt wie mglich zu halten, da Unterbrechungen in kurzen Abstnden ausgelst werden knnen. Der ARC-Prozessor verwaltet Unterbrechungen prioririsierungsgesteuert. Fr die HiCon Sammelunterbrechung wurde die mit hchster Prioritt ausgelegte und vom Benutzer freiprogrammierbare Unterbrechung mit der Nummer 4 gewhlt. Die Behandlungsroutine fr diese Unterbrechung muss in die Systemvektortabelle fr Unterbrechungen eingetragen werden. Der Sprungmechanismus in der Vektortabelle ist jedoch der Syntax eines C-Funktionsaufrufes nicht kompatibel. Diesbezglich wird bei der HiCon Lsung bei der Vektortabelle auf eine Metafunktion in Assembler verwiesen. Der Sprung in die Metafunktion sichert den Zustand des Prozessors auf den Systemstack und ruft die eigentliche Unterbrechungsroutine in C auf. Wenn die Unterbrechungsroutine terminiert, erfolgt der Rcksprung in die Metafunktion. Dort wird dann der alte Maschinenzustand wieder hergestellt.

9.2.7 Startkode
Die Laufzeitumgebung des Metaware Paketes benutzt eine fr unsere Ansprche berdimensionierte Startprozedur. Diese Art der Startinitialisierung ist mit groer 65

Anhang A: Handbuch fr den Simulator Wahrscheinlichkeit mit den potentiell benutzbaren Bibliotheksfunktionen verknpft. Da bei der Implementierung der Systemkontrolle auf Bibliotheksfunktionen verzichtet wird, wurde die Startprozedur auf ein Minimum reduziert. Die berarbeitete Startroutine ist Messergebnissen zufolge um cirka den Faktor 10 schneller als die ltere Version. Die neue Startroutine verbietet die Benutzung des mitgelieferten bersetzer/BinderMultimoduls, da die Binderaufrufe bei diesem Modul stets versuchen, die Standardstartroutine zu binden. Stattdessen muss das bersetzen und Binden manuell in zwei separaten Schritten erfolgen.

9.2.8 Zeitliches Verhalten der Komponenten ausnutzen


Die Steuerung der HiCon Komponenten ist zeitkritisch. Die Komponenten sollten nach dem Terminieren so schnell wie mglich fr die nchste Aufgabe parametrisiert und anschlieend gestartet werden. Es ist jedoch mglich, wertvolle Zeit zu gewinnen, indem man versucht, die Zeit zu nutzen, in der die Komponenten beschftigt sind. Es ist machbar, die Teile der Parameterberechnung, die nicht von den Rckgabewerten der Komponente abhngen sowie weiteren algorithmischen Aufwand, wie das Auffinden der zum nchsten Lauf bentigten Segmente oder das Reservieren der Segmente, die mit den Ausgabedaten der Komponente beschrieben werden sollen, in den besagten Zeitscheiben zu bewltigen. Um dies zu ermglichen, wird gleich nach dem Starten einer Komponente mit den Berechnungen fr den nchsten Lauf angefangen (siehe Abbildung 39).

66

Stand der Technik

B e r e c h n ur e n s g s l b z g l . F o r zm u a a k o n v e r t i e 2 r . uW n
g e

. F

l l s S p o u r c e t s- s e n S E t

e n

eg n n s t a r t e

i n

t a r t e n in h e i t
h e it

i c h e e s

r -

d e

W e n n B e s t t ig u n g v o n P a r a m e t e r e i n h e i t

P S

b e r t r a g e n d e r a r a m e t e r & p e i c h e r b e le g u
-

n g

a u

s g

E e f i n h h t e r i n h
n e

i t i t b

b e

r e i t
W e n n a u s g e f h r t

E
P a r a m e t e r b e r e c h n e n
V o n R c k g a b u n a b h n g i g e

s c h

f t i g t
P a r a m e t e r b e r e c h n e n 2
b P a e w e r a m r t e n e t e r V o n R c k g a b h n g i g e a

1
e w e r t e P a r a m t e r

a u

s g

h r t

W e n n B e s t t ig u n g v o n P a r a m e t e r e i n h e i t

S p e i c h e r -a u s g e f Wh r at r t e n a l l o z i i e r u n g E in h e it

u f
W e n n b e r e it E

P a r a m e t e r L e s e n v o n i d he e r i t E i n h e i t n

Abbildung 39: Steuerungsstrategie fr die Behandlung der HiCon Komponenten.

9.2.9 Verhalten beim Einschwingen


Beim Einschwingvorgang ist zunchst die HiCon Pipeline leer. Die erste Komponente, die mit der Arbeit beginnen kann, ist die Frontend Komponente. Whrend das Frontend das erste Eingabebild einliest, knnen die anderen Komponenten nicht starten (siehe Abbildung 40). Nach dem ersten eingelesenen Eingabebild knnen fr dieses Bild Bewegungsvektoren generiert werden. Diese werden jedoch solange als ungltig markiert, bis alle Bedingungen fr erfolgreiche Bewegungsschtzung existieren (siehe Kapitel 7.2.4). Bei dem zweiten eingehenden Eingangsbild wird somit neben der Frontend Einheit die Bewegungsschtzung gestartet. Die Zwischenzeilengenerierung und die Zwischenbildgenerierung starten ebenfalls, wenn die Bedingungen aus Kapitel 7 erfllt sind. Die Ausgabeeinheit startet als letzte Einheit, wenn gengend Bilder fr die Ausgabe vorhanden sind.

67

Anhang A: Handbuch fr den Simulator T 7

Z F r o

it

0 n
1 1

T d

1
2 2

2
3 3

3
4 4

4
5 5

5
6 6 5

6
7 7 6

n t e

B e w e g u n g s c h t z u n g Z w i s c h e n z e i l e n f i lt e r Z b i s c h e il d f il t e r w n -

s V -e
1

k t o

r e

l t i g

2
r t l i c h e F

3
i lt e r u n

4
g

F ( 1 )

F ( 2 )

F ( 3 )

F ( 4 )

F ( 5 )

F ( 2 ) r t l i c h e F

F ( 3 ) i lt e r u n g

F ( 4 ) -

F ( 5 ) -

F ( 1 ) + 1 1 + 1 1 +

F ( 2 ) +

F ( 4 ) +

F ( 5 ) +

c k e

n d

Abbildung 40: Systemtimingdiagramm fr das Einschwingverhalten im Vollbildmodus.

9.2.10

Verhalten bei Szenenwechsel

Wenn von der Systemkontrolle ein Szenenwechsel detektiert wird, wird durch den Umstand, dass das nun eintreffende Bildmaterial zum Bildmaterial im Speicher keinen Bezug mehr hat, die Bewegungsschtzung solange auf schlecht eingestuft, bis gengend Bilder fr die Rckwertschtzung vorhanden sind. Die eigentlich zwischen den zwei inhaltlich verschiedenen Eingangsbildern zu generierenden Bilder werden nicht ausgegeben. Statt der auszugebenen Bilder werden an den selben Positionen die Eingangsbilder wiederholt.

9.2.11

Movie Mode Behandlung

68

Stand der Technik Obwohl bei diesem Modus der Eingabestrom halbbildkodiert eintrifft, ist keine Halbbild/Vollbildwandlung ntig. Die beiden Filter sind somit nur mit der Zwischenbildgenerierung beschftigt. Obwohl ein Eingangsbildpaar ein vollbildkodiertes Eingabebild darstellt, werden fr alle halbbildkodierten Eingangsbilder Bewegungsvektoren erzeugt. Die fr jedes zweite Halbbild des Eingangsbildpaares erzeugten Vektoren sind qualitativ hochwertiger und werden somit nach ihrer Erzeugung fr die weiteren Operationen verwendet. Ferner werden bei diesem Modus fr die Generierung der Zwischenbilder der Chrominanzdaten nur die ersten Halbbilder des Chrominanzdatenpaares verwendet (Abbildung 41).

69

Anhang A: Handbuch fr den Simulator

Z F r o

e n

T it t e

0 n
N N a

T d

1
N N b b

2
N N N

T
+ 1 a + 1 a b

3
N N N

T
+ 1 b + 1 b + 1 a a ) b ) N

4
N N

T
+ 2 a + 2 a + 1 b N

5
N N

T
+ 2 b + 2 b + 2 a N

6
N N

T
+ 3 a + 3 b + 2 b + 2 a ) + 2 a )

B e w e g N u - 1n b g s c h t z u n g Z w i s c h e F n ( Nz e i l e n f i l t Ve ( rN

sN -a
- 1 a F) ( N - 1 b V) ( N

a ) F ( N a ) V ( N

F ( N V ( N

F ( N V ( N

- 1 ) - 1 a ) F ( N V ( N

F ( N V ( N - 1 ) + - 1 b )

) a ) F ( N V ( N ) + b )

F ( N V ( N

+ 2 ) + 2 a )

Z b

w i s c h il d f il t e

e r

c k e

B
C

e m
h r o m

L u m

i n a n z d a t e n

e r k u F n ( N e- 2 n ) : + g A l l

e p o s i t i v e n f r g e g e b e n e

F PB ( oiNn s d-i t 2ui on) n-g

e n

( N
D

- 2 )

i n a n z d a t e n B i n d u n g

A l l e n e g a t i v e n P o s i t i o n e n B i l d g e n e r i e r fu n r g g e g e b e n e B i n d u n g e i n t e r l a c i n g

V N N N a b
E r s t e s e i t e s a l s H a l b b i l d H Z w N

( N
o e v

a )
n N r g e g . O p e r a t i o n w e r d e n k tn o rN e n v o n N a b e n u t z t o

v F a l b b i l dV

V o l b i l d

Abbildung 41: Systemtiming bei Movie Mode Behandlung.

70

Stand der Technik

9.3 Implementierung des Simulators

9.3.1 Die Architektur des Simulators


Der Simulator wird in C++ fr Microsoft Windows Betriebssysteme entworfen. Sie ist als eine SDI (Single Document Interface) Dialoganwendung angelegt und benutzt die MFC (siehe [4]) API (Microsoft Foundation Classes Application Programming Interface). Die Applikation erbt, wie jede andere MFC Windows Applikation, von der Klasse CWinApp. Diese abgeleitete Klasse wird durch eine Sicht des Simulators und einen Messagehandler sowie eine Klasse CArc, die die Systemsteuerung abkapselt, erweitert. Die Sicht des Simulators, die fr die visuelle Reprsentation und Interaktion mit dem Benutzer verantwortlich ist, besteht aus verschiedenen Anzeige- und Bedienungselementklassen der MFC API. Diese werden der Klasse durch Aggregation hinzugefgt. Abbildung 42 zeigt das statische Klassendiagramm der Applikation.

71

Anhang A: Handbuch fr den Simulator

i n A

p C W i n D ia l o g C S e x a r le F t a t i c

G e n e r is c h e W i n d o w s a p p l i k a t io n k l a s s e d e r M F C . A ll e S D I W i n 3 2 P r o g T r h e A m p ep a m e r b e n d i e s Ae b g e l e i t e t e K l a s s e A p p li k a t i o n d e s S i m u la S t e l lt d e n S i m u l a t o r a W i n d o w s A + k a t i o n d a+ r .

T G e n e r is c h e d W in d o w s d i a lo g e k la s s e d e r M F C M s k l a s s e t o r s . ls p p li -

t f e n s t e r s t e ll u n g s m e n t d e r C

r c e m i a m e u lt d ie s t e u e s e K l t e t d s t e u t h o d e t e . C r u n g la s s e i e e r u n g n u n d e A r c D i a l o g C B u

D i e g e s t r i L in i e s t e h w e i t e r e K M F C , w e l B e d ie n e l e P r o g r a m m t t o n

c h e l t e t f r la s s e n d c h e d i e m e n t e d s d a r s t e

K a p s S y s t e e in . D b e i n h S y s t e a ls M A t t r ib

A b g e l e i t+ e D i a g l o g k+ l d e s S i m +u E r z e u g t + u v e r w a l t e+ t S i c h t d e s S i m u l a t o r

t e a s s e la t o r s . n d d i e s .

D r u c k k n o p f d a r s t e ll u n g s e le m e n t d e r M F C

Abbildung 42: Statisches Klassenmodell des Simulators.

9.3.2 Einbettung der Systemsteuerung in den Simulator


Die Klasse CArc enthlt eine leicht modifizierte Version der Systemsteuerung. Da die Sprache C eine Untermenge von C++ darstellt, kann die Systemkontrolle durch eine minimale syntaktische Modifikation in die besagte Klasse eingebettet werden. Dabei knnen die Funktionsprototypen der Systemkontrolle ohne weiteres als Methodennamen in die Klassendefinition bernommen werden. Der Funktionsname main() wird muss jedoch durch einen anderen Namen ersetzt werden. Ferner stellt die Funktion main() die Hauptiterationsschleife der Systemkontrolle dar. Sie ist in Form einer Endlosschleife realisiert. Durch den Umstand, dass die Hauptschleife der Systemkontrolle vom Simulator aus aufgerufen wird und dass der Simulator die Kontrolle jedoch nach einer vom Benutzer angegebenen Anzahl von Iterationsschritten wieder zurckerlangen muss, damit das Programm weiterhin auf die Eingabe des 72

Stand der Technik Benutzers reagieren kann, muss diese Schleife in eine endliche Form gebracht werden. Die Anzahl der erwnschten Iterationsschritte wird durch Methodenparameter berreicht. Die eigentliche Implementierung der Methoden findet, wie bei C++ blich, auerhalb der Klasse statt. Hierbei mssen die Funktionen aus der Systemkontrolle durch den Namenraum der Klasse erweitert werden. Dieses geschieht durch den :: Operator. Auch globale Variablen knnen ohne weiteres auch als Klassenattribute bernommen werden. Sowohl die Klasse fr das Steuerprogramm als auch die Klasse fr die Sicht des Simulators haben gegenseitig Referenzen auf einander. Durch diese Referenzen knnen die Benutzereingaben des Simulators an die Systemkontrolle ungeleitet werden. Es ist ferner mglich, durch die Referenzen die Ausgabe der Systemsteuerung in die visuelle Reprsentation umzuleiten. Deshalb mssen jedoch die Befehle, die die Systemsteuerung an die HiCon Komponenten sendet, in einer textuellen Form an die Sicht des Simulators berreicht werden.

73

Anhang A: Handbuch fr den Simulator

10 Optimierung
10.1Generelle Optimierungsstrategien
Hierbei werden allgemeine Optimierungsstrategien aufgefhrt, die nicht speziell im Kontext der Systemkontrolle entworfen sind.

10.1.1

Zeigerarithmetik

Auf Felder kann in C sowohl mit Feldindizes als auch mit Zeigern zugegriffen werden. Der Zeigerzugriff geschieht etwas schneller als die Feldindexvariante, und ist damit bei Optimierungsbedarf vorzuziehen.

10.1.2

Zeitkritische Funktionen in Assembler

Zeitkritische Funktionen knnen optimiert werden, indem sie in Assembler berfhrt werden. Der effektivste Weg ist, auf folgende Weise vorzugehen: 1) Funktion in C implementieren. 2) bersetzer mit der Option starten, eine Assemblerquelldatei zu erzeugen. 3) Die betroffenen Funktion in Assembler berarbeiten (optimieren).

10.1.3

Integerarithmetik vs. Fliekommaarithmetik

Algorithmen mit Fliekommaarithmetik knnen unter Einschrnkung der Genauigkeit auf Integerarithmetik konvertiert werden. Diese Optimierung bringt einen signifikanten Geschwindigkeitsvorteil. Dieser Schritt erfordert jedoch eine genaue Betrachtung der Wertebereiche der an der Berechnung beteiligten Gren.

74

Stand der Technik

10.2Optimierung des Vollbildmodus

10.2.1

Optimierungskonzept

Beim Vollbildmodus wurden weitere Mglichkeiten fr Optimierungsarbeiten entdeckt. Die Grundidee hierbei ist es, die Bedingungen die fr die Steuerung der Komponenten (siehe Kapitel 7 und 9) und zum Bestimmen der anliegenden Konvertierungsschritte in diesem Modus in eine Programminfrastruktur einzubetten. Dadurch entsteht ein Mechanismus, dessen Funktionieren die Invarianten der Spezifikation abdeckt. Weil dieser Mechanismus die Kausallogik ersetzt, wird das Programm von der Gre her kleiner und die Abarbeitungsgeschwindigkeit erhht sich.

10.2.2

Optimieren hinsichtlich des Systemtimings

Es ist fr die angestrebte Art der Optimierung wichtig, die Steuerung der verschiedenen Komponenten zu synchronisieren. In Abbildung 35 sind die unterschiedlichen Wandlungsschritte immer zu den frhest mglichen Zeitpunkten eingetragen, in denen die Bedingungen fr diese Wandlungsschritte erfllt sind. Eine Studie dieses Diagramms lsst darauf schlieen, dass die Steuerung der Ausgabe sich nicht mit der Steuerung fr den Rest der Komponenten vereinen lsst. Somit bleibt die Ausgabe diesbezglich ein asynchroner Prozess. Wenn jedoch das Timingdiagramm wie in Abbildung 43 dargestellt modifiziert wird, indem einige Wandlungsschritte auf der Zeitachse in positiver Richtung verlegt werden, kann das Einlesen eines Eingangsbildpaares als eine Synchronisationszeitscheibe erkannt werden. In der Zeit, in der das Einlesen des Bildpaares stattfindet, muss die Bewegungsschtzung ein Blockvektorbild generieren knnen. Ebenso mssen die Filter in der Lage sein, ihre Wandlungsschritte durchzufhren. Hierbei fllt ferner auf, dass wenn das Frontend am Bild n arbeitet, die Bewegungsschtzung stets mit der Generierung der Blockvektoren fr Bild n-1 beschftigt ist. Die Filter arbeiten in der besagten Zeitscheibe an der

75

Anhang A: Handbuch fr den Simulator Generierung der Sttzbilder um das Eingangsbild n-2 herum. Ferner fllt auf, dass die Steuerung der beiden Filter zusammengefasst werden kann.

Z F r o

it

0 n
N N

T d

1
N N + 1 + 1

2
N N N + 2 + 2 + 1 )

3
N N N + 3 + 3 + 2

4
N N N + 4 + 4 + 3

5
N N N + 5 + 5 + 4

6
N N N + 6 + 6 + 5

n t e

B e w e g u n g s c h t z uN -n 1 g Z w i s c F h ( N -n 2 -)F e z e i l e n f i lt e r
F ( N

s N

( N

- 1 ) F ( N

F ( N

+ 1 F) ( N

+ 2 F) ( N

+ 3 )F ( N

+ 4 )

- 2 )F - ( N

- 1 ) -F ( N

) -

F ( N

+ 1 F ) (- N

+ 2 F) - ( N

+ 3 F) - ( N

+ 4 ) -

Z w i s c h b il d f il t e

F ( N

e n r

- 1 ) F+ ( N ) + F ( N N N N N N N + + + 1 ) + F ( N + 3 )F + ( N + 4 ) +

- 2 )F + ( N

c k e

n d

Abbildung 43: Systemtimingdiagramm fr den optimierten Vollbildmodus.

10.2.3

Zentralisieren des Algorithmus und das Vorerfassen der

Wandlungsschritte
Um nicht bei allen kontrollierenden Zustandsmaschinen den Algorithmus zur Bestimmung der ntigen Wandlungsschritte zu durchlaufen, wird der Algorithmus in eine separate Zustandsmaschine eingebettet. Diese Zustandsmaschine wird als Generator bezeichnet. Der Generator ist fhig, abhngig vom Wandlungsverhltnis, fr ein Sttzbild (Bindung) alle ntigen Positionen zu liefern, an denen Bilder generiert werden mssen. Dieses Konzept wird durch eine als Paket bezeichnete Datenstruktur zustzlich untersttzt (siehe Abbildung 44). Ein Paket reprsentiert ein durch eine 76

Stand der Technik eindeutige Identifizierungsnummer gekennzeichnetes Sttzbildpaar (package.id). Diese Identifizierungsnummer wird fr jedes kommende Eingangsbildpaar hochgezhlt. Die Identifizierungsnummer wird ab nun auch bei der Belegung der Segmente verwendet. Wenn der Generator ein solches Paket bearbeitet, trgt er die Positionen der zu generierenden Bilder und die jeweilige Anzahl der Bilder an einer bestimmten Position in die Felder package.neg sowie package.pos ein. Dabei werden die vor dem Sttzbild liegenden Positionen in Feld package.neg und die zeitlich nach dem Sttzbild folgenden Positionen in den Feld package.pos eingetragen. package.display gibt Auskunft darber, wie oft das Sttzbild in der Ausgabesequenz an Position 0 ausgegeben wird. Ferner wird ein Konzept des Vorberechnens eingefhrt, in dem der Generator fr das, in der kommenden Synchronisationszeitscheibe zu erwartende Eingangsbildpaar, die Positionen der zu generierenden Bilder ermittelt und in einem Paket eintrgt. Dieses Paket wird bei der nchsten Synchronisationszeitscheibe an die das Frontend kontrollierende Zustandsmaschine weitergereicht. Diese reserviert anhand der Identifikationsnummer die ntigen Segmente und findet, mit Hilfe der fortlaufenden Nummerierung, die weiteren Segmente fr die bentigten Bilddaten (siehe Tabelle 15). Wenn das Paket und somit das Sttzbildpaar die Nummer n hat, werden die bentigten Segmente mit den Vorgngervektoren die Nummer n-1 haben. Wenn bei diesem Sttzbild ein Szenenwechsel detektiert wurde, wird es bei package.cut vermerkt. Bei der anschlieenden nchsten Synchronisationszeitscheibe wird das Paket an die Steuerung der Bewegungskontrolle weitergereicht. Das Auffinden und Belegen der ntigen Segmente erfolgt wie bei der Frontend Einheit. Bei dieser Instanz wird die Gte der Vektoren bei package.use_vecs eingetragen. Bei der nchsten Synchronisationszeitscheibe generiert die Zustandsmaschine, die die beiden Filter steuert, anhand den im Paket enthaltenen Informationen die bentigten Zwischenbilder. Die bentigten Segmente werden wieder anhand der Identifikationsnummerierung verwaltet. Die Filter mssen in der Synchronisationszeitscheibe je nach Wandlungsverhltnis mehrmals gestartet werden. Die Information ber die fertiggenerierten Bilder sowie die der Eingabebilder werden in der richtigen Reihenfolge in eine Ausgabequeue gesteckt. Diese Queue enthlt als Eintrge nur die Information ber die Position und Bindung der jeweiligen Bilder. Somit kann die Kontrolle der

77

Anhang A: Handbuch fr den Simulator Ausgabeeinheit, anhand der in der Queue befindlichen Eintrge, die Segmente der Ausgabebilder ber den Speicherabbild lokalisieren und ausgeben.
struct bit2 { unsigned char data:2; }; /* datatype of a two bit char */ /* this struct has the characteristic data of a task to be done it contains a original input picture and has information about the to be generated pictures araound the original one*/ struct package{ unsigned char id; unsigned char dummy:1; /* indicates that the information contained in this record has no use */ unsigned char display:3; /* # display ops for the source picture */ unsigned char use_vecs:1; /* use vectors : 1 yes / 0 no */ unsigned char cut:1; /* flag for cut */ /* checklist for pictures to generate */ struct bit2 neg[12];/* position [-16 to -5] */ struct bit2 pos[11]; /* position [+5 to +15] */
Abbildung 44: Paketstruktur in C

/* id number */

Tabelle 15 : Speicherbelegung im Vollbildmodus.

Zustandsmaschine Generator Frontend

Belegung der Segmente Keine o Eingabebild Luminanzanteil o Eingabebild Chrominanzanteil o Quincunx Bilder

Bewegungsschtzung Filter Backend

o Nonquincunx Bilder Bewegungsvektoren o Luminanzanteil der erzeugten Bilder o Chrominanzanteil der Erzeugten Bilder Keine

78

Stand der Technik

10.2.4

Paketrotation

Da nun aber die Komponenten parallel arbeiten, werden insgesamt vier statische Pakete bentigt. Wie in Abbildung 45 illustriert, werden die Pakete von ein bis vier durchnummeriert. Innerhalb einer Synchronisationszeitscheibe arbeitet der Generator an dem als nchstes fr das Frontend in Frage kommendem Paket. Die Kontrolle des Frontend arbeitet in der selben Zeitscheibe an dem Vorgngerpaket des Generators. Die Kontrolle der Bewegungsschtzung hingegen arbeitet an dem Vorgngerpaket der Fronendkontrolle. Und letztlich arbeitet die Filterkontrolle an dem Vorgngerpaket der

k e

G P

e n F S
S

e r a M
1 S 2

t o

k e

F P

r o n t e F S M
S 1 S 2

d A b b i l d d e s D a t e n s p e i c h e u n g s .

r s

k e

B P

e F

w S
S 1

e g M
S 2

F P a k e t 4 P 3

i lt e
S 1

B F

a c k e I F O

B P

a F

c k e S M
S 1 S 2

Abbildung 45: Schematische Darstellung fr den optimierten Vollbildmodus.

Bewegungsschtzung. Wenn die Zustandmaschinen fr die Kontrolle der Einheiten jeweils ihre Pakete abgearbeitet haben, kann die nchste Synchronisationszeitscheibe begonnen werden. Dieses wird durch ein zyklisches Weiterreichen der Pakete gestartet. 79

Anhang A: Handbuch fr den Simulator Damit werden die Bilder in der Pipeline weitergereicht. Die Pakete werden wie in Abbildung 46 rotiert. Dabei werden die Schritte eins bis vier durchlaufen. Von Schritt vier findet ein bergang zu Schritt eins statt. Durch diesen Mechanismus ist gewhrleistet, dass die jeweiligen Bedingungen fr die anliegenden Wandlungsschritte der jeweiligen Einheiten stets erfllt sind. Somit mssen die Bedingungen von Kapitel 7 nicht separat abgeprft werden.

Generator Frontend Motion Filter

Paket 1 Paket 2 Paket 3 Paket 4

Generator Frontend Motion

Paket 3 Paket 4 Paket 1 Paket 2

1 2

3 I 4

Filter

Generator Frontend Motion Filter

Paket 4 Paket 1 Paket 2 Paket 3

Generator Frontend Motion Filter

Paket 2 Paket 3 Paket 4 Paket 1

Abbildung 46: Paketrotation beim optimierten Vollbildmodus

10.2.5

Speicherfreigabe

Die Speicherfreigabe erfolgt nach einem Kaskadenmodell. In diesem Modell geben immer die Zustandsmaschinen Speichersegmente frei, die die jeweiligen Segmente als letzte Instanz bentigen (siehe Tabelle 16).

80

Stand der Technik


Tabelle 16: Speicherfreigabe beim Vollbildmodus.

Zustandsmaschine Generator Frontend Bewegungsschtzung Filter Backend

Segmenttypen zur Freigabe keine Keine o Nicht bentigte Quincunx Bilder o Nicht bentigte Nonquincunx Bilder Nicht bentigte Vektoren o Nicht bentigte Chrominanzzwischenbilder o Nicht bentigte Luminanzzwischenbilder o Ausgegebene Chrominanzeingangsbilder o Ausgegebene Luminanzeingangsbilder

81

Anhang A: Handbuch fr den Simulator

11 Verifizierung

11.1Verifizierung mit dem Simulator


Bei der Verifizierung der Systemsteuerung mittels des dafr entworfenen Simulators ist das Verhalten der Systemsteuerung mit den in Kapitel 9 eingefhrten Systemtimingdiagrammen zu vergleichen. Ferner mssen vom Programm die in der Spezifikation eingefhrten Kriterien eingehalten werden. Die Verifizierung mit dem Simulator bietet auerdem Informationen ber die Speicherausnutzung der Systemkontrolle sowie das Verhalten der Systemkontrolle bei unplanmigem Laufzeitverhalten der HiCon Komponenten. Schlielich geben die Verifizierungsarbeiten mit dem Simulator Auskunft ber das Verhalten der Systemkontrolle bei Szenenwechsel sowie ber das Einschwingverhalten. Die Tests mit dem Simulator knnen aber nicht Auskunft ber die Korrektheit hinsichtlich der Kommunikation mit den Einheiten und somit der Parameterbertragung geben. Diese Verifizierungsmethode bietet alle Informationen ber die algorithmische Korrektheit der Systemsteuerung, und wird somit als essenzieller Ausgangspunkt fr weitere Verifizierungsarbeiten klassifiziert.

11.2Verifizierung mit dem HiCon Ersatzmodell


Um die Parameterbertragung auf Korrektheit zu testen, wurde ein weiteres Testkonzept erarbeitet. Dieses Konzept sieht vor, die Systemkontrolle auf einem ARCProzessor mit einer voll funktionsfhigen Parametereinheit und einem Parameterbus zu testen. Da die HiCon Komponenten zu dem gegenwrtigen Zeitpunkt noch nicht fertig implementiert bzw. vollstndig gestestet sind, werden diese Komponenten gegen Ersatzmodelle ausgetauscht. Die Ersatzmodelle der Komponenten lassen sich bei Betriebsbereitschaft starten und terminieren selbstndig nach einer voreingestellten Zeit. Somit finden die Verifizierungsarbeiten auf einem speziellen System statt. Dieses 82

Stand der Technik System arbeitet mit dem Modelsim Simulator auf der HDL-Ebene. Zuzglich ist, durch eine von Argonaut mitgelieferte RASCAL Schnittstelle, eine Auswertung und Darstellung des ARC-Prozessors mit dem ausgefhrten Programm in einem grafischen Debugger mglich. Sowohl der HDL-Simulator als auch der grafische Debugger sind miteinander synchronisiert, und bieten somit verschiedene Sichten fr das selbe Problem. Diese Art der Verifizierung ist zeitlich extrem aufwndig. Zu dem gegenwrtigen Zeitpunkt wurden die Tests fr den Vollbildmodus begonnen. Sie sind jedoch noch nicht abgeschlossen. Der Halbbildmodus wurde noch nicht mit dieser Methodik getestet.

11.3Weitere Verifizierungsarbeiten in der Zukunft


Wenn die HiCon Komponenten bereitstehen, wird der Gesamttest auf der Systemebene ausgefhrt. Ab diesen Zeitpunkt wird eine vollstndige Formatkonvertierung mit dem ASIC mglich sein. Somit wird als abschlieende Verifizierung die Ausgangssequenz der Formatkonvertierung berprft werden. Auerdem wird es mglich sein, das zeitliche Zusammenspiel von Systemkontrolle, Kernkomponenten und Datenbus unter reellen Bedingungen zu testen.

83

Anhang A: Handbuch fr den Simulator

12 Bewertung der Arbeit und weitere Ausblicke


Die Ziele dieser Arbeit, eine zeitkritische und kompakte Steuerung fr einen komplexen ASIC konzeptuell zu erarbeiten und anschlieend zu implementieren, werden an dieser Stelle bewertet. Gleichzeitig werden noch offen stehende Schritte sowie Mglichkeiten fr zuknftige Erweiterungen errtert. Das Konzept, die Systemkontrolle als Software fr einen eingebetteten Prozessor zu realisieren, hat sich bis zu diesem Zeitpunkt als vorteilhaft erwiesen. Das Kriterium einer spteren Erweiterbarkeit sowie Verbesserbarkeit bringt signifikante Vorteile gegenber einer fest verdrahteten Variante. Als weiterer Vorteil hat sich die schnelle Realisierbarkeit der Software-Variante erwiesen. Falls der Umfang der Systemkontrolle zu einem spteren Zeitpunkt feststehen sollte, knnen die entwickelten Programme in Schaltungen berfhrt werden. Diese Manahme wrde zweifellos die Produktionskosten des ASICs senken, da sich der externe Speicher verringert. Die Entscheidung quasiparallele Zustandsmaschinen anstelle von Threads zu benutzen, macht dies mglich. Es hat sich ferner besttigt, dass das Verzichten auf Bibliotheken und Threads entscheidende Vorteile bei der Programmgre sowie der Ausfhrungsgeschwindigkeit bringen. Diese Vorteile wurden aber mit Einbssen in der Einfachheit und somit der Verstndlichkeit der Programme erkauft. Es wurde weiter ein Weg gefunden, den Vollbildmodus grundlegend zu optimieren. Der optimierte Vollbildmodus hat gegenber dem unoptimierten Halbbildmodus hinsichtlich der benutzten Ressourcen viele Reserven. Diese Beobachtung fhrt zu der Erkenntnis, den Halbbildmodus hinsichtlich eines vorhandenen Optimierungspotentials weiterhin zu erforschen. In der Zukunft sollte ferner weiterhin erforscht werden, ob sich die beiden Modi eventuell doch vereinen lassen. Die Verifizierungsarbeiten die in Kapitel 11 unter Schritt zwei und drei vorgestellt wurden, mssen fr beide Modi vollstndig durchlaufen werden. Wobei Schritt drei die komplette Implementierung und Verifizierung aller Komponenten voraussetzt. Nur so knnen alle mglichen Seiteneffekte, die bei der Gesamtverschaltung des Konverters entstehen, aufgedeckt werden. Es ist zu Zeit nicht auszuschlieen, dass die sich in der 84

Stand der Technik Zukunft ergebenden Vernderungen und Verbesserungen an dem Konverter, weitere Arbeiten an der Systemkontrolle mit sich ziehen. Doch das trotz Verbesserungen bei der Spezifikation sowie bei den Einheiten, das Konzept der Systemkontrolle sich als richtig erwiesen hat, beweist die Qualitt der entwickelten Konzepte und deutet auf gengend Vernderungspotential hin. So das die Systemkontrolle in solchen Fllen nicht neu implementiert, sondern lediglich modifiziert werden wird. Zusammenfassend kann behauptet werden, dass die gesetzten Ziele grtenteils und zu allgemeiner Zufriedenheit im Projekt erreicht wurden. Obwohl bedingt durch die noch nicht abgeschlossene Entwicklung weitere Verifizierungsarbeiten an der Systemkontrolle offen stehen.

85

Anhang A: Handbuch fr den Simulator

13 Abbildungsverzeichnis
Abbildung 1: Die Anfangssequenz..............................................................................3 Abbildung 2: Frequenzverdoppelung durch Bildkopierung.......................................4 Abbildung 3: Schwchen bei der Bildkopierung........................................................5 Abbildung 4: Das Skalieren durch Bildpunktvervielfachung ohne Kantenglttung.6 Abbildung 5: Ausgangssequenz halbzeilenkodiert....................................................6 Abbildung 6: Originalsequenz in einem groben Bildpunktraster dargestellt............7 Abbildung 7: Deinterlacing durch Zeilenverdoppelung.............................................7 Abbildung 8: Deinterlacing durch Bildverschachtelung............................................8 Abbildung 9: Quincunx Unterabgetastete Bilder als Eingabe der Bewegungsschtzung................................................................................................10 Abbildung 10: Die bentigten Bilder fr die Bewegungsschtzung........................11 Abbildung 11: Die Vektorkandidaten bei der manderfrmigen Bewegungsschtzung................................................................................................12 Abbildung 12: Die Zwischenbildfilterung. ................................................................13 Abbildung 13: Die streifenweise Abarbeitung...........................................................14 Abbildung 14: Die Zwischenzeilenfilterung...............................................................15

86

Stand der Technik Abbildung 15: bersicht von HiCon auf toplevel Systemebene..............................17 Abbildung 16: Ein- und Ausgnge der Frontend Komponente................................18 Abbildung 17: Ein- und Ausgnge der Bewegungsschtzer Komponente.............19 Abbildung 18: Ein- und Ausgnge der Zwischenzeilenfilter Komponente..............20 Abbildung 19: Ein- und Ausgnge der Zwischenbildfilter Komponente.................20 Abbildung 20: Ein- und Ausgnge der Backend Komponente................................21 Abbildung 21: Ein- und Ausgnge der Audioverzgerung Komponente................21 Abbildung 22: Schematische Darstellung der Parametereinheit/Systemkontrolle/Kern-Verschaltung............................................22 Abbildung 23: Der Parameter Bus ist als Daisy-Chain-Bus implementiert.............23 Abbildung 24: Speicherverwaltung aus drei Sichten:..............................................24 Abbildung 25: Der zentrale bidirektionale Datenbus mit separaten Kontrollleitungen zu jeder Kernkomponente............................................................25 Abbildung 26: Die vertikalen Balken stellen die Bilder der Eingangssequenz dar.28 Abbildung 27: 31 mgliche Positionen zum erzeugen der Knstlichen Bilder befinden sich zwischen zwei Eingansbildern...........................................................28 Abbildung 28: Die Positionen haben verschieden Zugehrigkeiten.......................29 Abbildung 29: Der komplette Bindungsbereich eines Eingabebildes.....................29

87

Anhang A: Handbuch fr den Simulator Abbildung 30: Die Eingangs- (oben) sowie Ausgangssequenz (unten) bei einer Wandlung. ...................................................................................................................30 Abbildung 31: Schematische Darstellung einer quasiparallelen Zustandsmaschine......................................................................................................52 Abbildung 32: Quelltext einer quasiparallelen Zustandsmaschine.........................53 Abbildung 33: Verfeinerung der Zustnde................................................................54 Abbildung 34: Erklrung der benutzten Notation bei den Timingdiagrammen......55 Abbildung 35: Systemtiming bei Vollbildmodus.......................................................56 Abbildung 36: Datenabhngigkeiten beim Vollbildmodus.......................................57 Abbildung 37: Systemtiming fr Halbbildmodus......................................................58 Abbildung 38: Datenabhngigkeiten beim Halbbildmodus......................................59 Abbildung 39: Steuerungsstrategie fr die Behandlung der HiCon Komponenten. 67 Abbildung 40: Systemtimingdiagramm fr das Einschwingverhalten im Vollbildmodus.............................................................................................................68 Abbildung 41: Systemtiming bei Movie Mode Behandlung..................................70 Abbildung 42: Statisches Klassenmodell des Simulators.......................................72 Abbildung 43: Systemtimingdiagramm fr den optimierten Vollbildmodus...........76 Abbildung 44: Paketstruktur in C ..............................................................................78

88

Stand der Technik Abbildung 45: Schematische Darstellung fr den optimierten Vollbildmodus.......79 Abbildung 46: Paketrotation beim optimierten Vollbildmodus................................80 Abbildung 47: Benutzeroberflche des Simulators.................................................97

89

Anhang A: Handbuch fr den Simulator

14 Tabellenverzeichnis

Tabelle 1: Zusammenfassende Spezifikation der Eingangsdatenbehandlung.......34 Tabelle 2: Zusammenfassende Spezifikation der Bewegungsschtzungsbehandlung...........................................................................34 Tabelle 3: Zusammenfassende Spezifikation der Behandlung fr die Zwischenzeilengenerierung.......................................................................................36 Tabelle 4: Zusammenfassende Spezifikation der Behandlung fr die Zwischenbildgenerierung bei halbbildkodierter Eingangsdaten.............................36 Tabelle 5: Zusammenfassende Spezifikation der Behandlung fr die Zwischenbildgenerierung fr Chrominanzdaten bei halbbildkodierter Eingangsdaten............................................................................................................37 Tabelle 6: Zusammenfassende Spezifikation der Ausgabedatenbehandlung bei halbbildkodierter Eingangsdaten...............................................................................38 Tabelle 7: Zusammenfassende Spezifikation der Behandlung fr die Zwischenbildgenerierung fr Luminanzdaten bei vollbildkodierte Eingangsdaten. 38 Tabelle 8: Spezifikation der Behandlung fr die Zwischenbildgenerierung fr Chrominanzdaten........................................................................................................39 Tabelle 9: Spezifikation der Bildausgabe..................................................................40

90

Stand der Technik Tabelle 10: Die von Modus abhngige Aufteilung des Speichers in Speichersegmente und die Belegung der einzelnen Segmente..............................60 Tabelle 11: Datenstruktur fr ein Segment ...............................................................63 Tabelle 12: Datenstruktur fr ein Segment der ........................................................63 Tabelle 13: Datenstruktur fr generierte Bilder. .......................................................63 Tabelle 14: Datenstruktur fr Halbbildmodus ..........................................................63 Tabelle 15 : Speicherbelegung im Vollbildmodus.....................................................78 Tabelle 16: Speicherfreigabe beim Vollbildmodus...................................................81

91

Anhang A: Handbuch fr den Simulator

15 Literaturverzeichnis
[1] Peter J. Ashenden The Students Guide to VHDL Morgan Kaufmann Publishers, Inc. (1998) [2] Brian W. Kernigham, Dennis M. Ritchie Programmieren in C (2. Auflage) Carl-Hanser (1999) [3] Bjarne Stroustrup Die C++ Programmiersprache (3. Auflage) Addison Wesley (1998) [4] Microsoft Cooperation Microsoft Foundation Class Reference Part 1 & 2 Microsoft Press (1995) [5] Hans Liebig, Thomas Flik Rechnerorganisation Springer-Verlag (1993) [6] Kai-Immo Wels Entwicklung von synthesefhigen VHDL-Komponenten zur Anpassung und Konvertierung von Videodaten HHI/TUB (2000) [7] ARC Development Toolkit Release v2.1.2e Documentation Argonaut Technologies Ltd. (1998)

92

Stand der Technik

[8]

Metaware Cooperation High C/C++ Manual Erhltlich mit dem Erwerb von Metaware High C/C++

93

Anhang A: Handbuch fr den Simulator

Anhang A: Handbuch fr den Simulator

Grundkonzept des Simulators


Die Idee hinter dem Simulator ist es, eine Mglichkeit zu finden, womit man die Systemkontrolle auf Korrektheit testen kann, bevor HiCon als ASIC testbereit ist. Ferner soll der Benutzer in die Lage versetzt werden, auf eine zugngliche visuelle Art die Ablufe in der Systemkontrolle zu beobachten. Der Simulator beinhaltet den Programm fr die Systemkontrolle, jedoch wird der Rest von HiCon virtuell abgebildet. Der Simulator konvertiert deshalb auch keine Bildersequenzen. Der Benutzer ist in der Lage, die Start-/Stopvorgnge der Einheiten zu verfolgen. Der Simulator zeigt ferner das Abbild des Datenspeichers mit der aktuellen Belegung und er zeigt bei den Startvorgngen der Einheiten, welche Segmente in den Vorgngen involviert sind. Auerdem kann der Benutzer sich ber die jeweiligen Zustnde der Kontrollzustandsmaschinen informieren. Der Benutzer ist dafr zustndig, die virtuellen Einheiten des ASIC terminieren zu lassen. Diese Vorgehensweise hat den entscheidenden Vorteil, dass alle mglichen Szenarien, beispielsweise dass eine Einheit im Verzug ist, durchspielen zu knnen.

Die Bedienung des Simulators


Nach dem Aufrufen des Programms erscheint die in Abbildung 46 dargestellte, graphische Benutzeroberflche des Simulators. Dabei muss der Benutzer als erstes das Wandlungsverhltnis angeben. Der Simulator ist kategorisch in folgende Bereiche aufgeteilt:

1) Abbild des Datenspeichers:

94

Stand der Technik Hierbei werden die fr den Modus abgestimmte Speicherpartitionierung und die einzelnen Segmente mit deren aktuellen Belegungen abgebildet. Speichersegmente knnen entweder frei (free) oder belegt sein. Bei belegten Speichersegmenten wird die entsprechende Bildung gezeigt. Bei Zwischenbildern trifft zustzlich die Position bei der Belegung auf.

2) Status der Einheiten:


Die Zustnde der verschiedenen HiCon Komponenten werden durch Kontrolllampen dargestellt. Dabei bedeutet eine rot leuchtende Lampe, dass die Einheit arbeitet. Grn leuchtende Lampen hingegen signalisieren die Bereitschaft der Einheiten.

3) Programminterner Zustand:
Diese Informationen sind fr den Programmierer bestimmt, sie stellen ein Abbild des internen Zustands des Programms zur Systemsteuerung dar. Sie werden deshalb an dieser Stelle nicht weiter erlutert.

4) Die Kontrollelemente:
Mit diesen Elementen kann man laufende Einheiten terminieren oder die Simulation weiter iterieren lassen. Dabei haben die Buttons folgende Bedeutung: Step,Step5,Step10,etc.:

Lsst die Simulation in den angegebenen Schritten weiterlaufen. StopFE,StopME,StopILF,StopIFF,StopBE:

Stoppt die jeweilige laufende Einheit.

95

Anhang A: Handbuch fr den Simulator Cut:

Ruft einen Szenenwechsel hervor. MM(nur bei Halbbildmodus):

Ruft die Movie Mode Behandlung hervor.

5) Ausgabe der Systemkontrolle:


Hier werden textuell die Startvorgnge der Komponenten und andere Arten der Kommunikation des Arc zu den Komponenten dargestellt.

6) Zustande der Kontrollzustandmaschinen:


Hier werden die augenblicklichen Zustnde der Kontrollzustandmaschinen aufgefhrt. Mgliche Zustnde sind: Switch (nur bei Vollbildmodus): Warten auf die nchste Synchronzeitscheibe. WaitUnit: Warten auf die Terminierung der kontrollierten Komponente. MemMap: Segmentverwaltung und Parameterberechnung. GetPars: Parameter lesen von der Komponente. Recalc: Berechnen von Parametern anhand Rckgabewerte. Write: Parameter schreiben und Einheit starten.

96

Stand der Technik


Abbildung 47: Benutzeroberflche des Simulators

6 2

97