Web-Interface for Multi-FPGA Board Pamette Einleitung Vorstellung Semesterarbeit Web-Interface for Multi-FPGA Board Pamette Studenten: Moritz Ritter / Christoph Aschwanden Assistenten: Michael Eisenring / Dr. Marco Platzner Professor: Prof. Dr. L. Thiele

Aufgabenstellung Motivation: DSP / FPGA Boards sind teuer Hauptteil Aufgabenstellung Motivation: DSP / FPGA Boards sind teuer Teilen der Boards unter verschiedenen Benutzern Web-Interface entwickeln, damit vom Internet aus jeder auf die Boards zugreifen kann

Aufgabenstellung Ziele: Web-Interface für Hard- und Software: Hauptteil Aufgabenstellung Ziele: Web-Interface für Hard- und Software: - Plattformunabhängigkeit - Überall aus dem Internet ansprechbar - Billig (oder gratis) - Einfach zu benutzen (neue Module dazufügen) - XHWIF Applikationen müssen laufen Daraus ergeben sich folgende Zielsetzungen: - Das System sollte .... sein. - Und: als Zusatz sollten auch die XHWIF Applikationen und Treiber von unserem Interface weiter benutzt werden können.

XHWIF? Xilinx HardWare InterFace  Zugriff vom Internet möglich Hauptteil XHWIF? Xilinx HardWare InterFace  Zugriff vom Internet möglich  Plattformunabhängig da Java programmiert  Applikationen und div. Boardtreiber vorhanden  Funktionalität nicht vollständig  Erweiterbarkeit eingeschränkt  kein Sourcecode vorhanden  Unser Interface soll XHWIF Applikationen und Treiber weiter verwenden können. - XHWIF wird von Xilinx als Interface für den Zugriff auf verschiedene FPGA-Boards angeboten. - besteht aus ca. 20 FPGA-spezifischen Funktionen. - Es verfügt über eine Socket basierte Internet Zugriffs Möglichkeit. - Da es in Java programmiert ist, ist es Plattform unabhängig. - Es gibt bereits eine grafische remote control Anwendung für dieses Interface: BoardScope. - Und das schönste daran ist, dass es von Xilinx bereits ca. ein Duzend Treiber für FPGA basierte Boards gibt. - Leider ist die Funktionalität stark eingeschränkt. Es ist zum Beispiel nicht möglich, die Ports des Pamette boards abzufragen, während dem dessen Clock eingeschaltet ist. Deshalb muss man um Infos vom Board zu lesen, dieses jedes Mal anhalten, den ganzen Inhalt auslesen und das Board wieder starten, was natürlich sehr ineffizient ist. - bla bla

Lösungsansätze Lösungsmöglichkeiten I: -RMI Problem: Plattformabhängig Hauptteil Lösungsansätze Lösungsmöglichkeiten I: -RMI -ActiveX Problem: Plattformabhängig -IDL Problem: Nicht für Client-Server Anwendungen Java Client Java Server RMI

Lösungsansätze Lösungsmöglichkeiten II: -Sockets z.B. XHWIF (Xilinx) Hauptteil Lösungsansätze Lösungsmöglichkeiten II: -Sockets z.B. XHWIF (Xilinx) -Webserver mit CGI / ASP / PHP / Servlets Client Server Socket Webserver Client Servlets Internet

Die Lösung - GHWIF General Hard- and softWare InterFace Hauptteil Die Lösung - GHWIF General Hard- and softWare InterFace -Basis: Apache JServ Servlet. -Bietet nur 5, dafür mächtige Funktionen an. -XHWIF Unterstützung Nun kommen wir zu unserer Lösung, welche wir GHWIF für General Hard- and softWare InterFace genannt haben. - bla bla

GHWIF Funktionen 5 mächtige Funktionen: Hauptteil GHWIF Funktionen 5 mächtige Funktionen: -read(long target, long length) -write(long target, long length, byte[] data) -start(long fnr, long length, byte[] data) -stop() -getStatus() GHWIF besteht aus 5 mächtigen Funktionen: - Die Funktion read() wird verwendet um einen zusammenhängenden Datenblock von einem Server Modul zu lesen, - write() um einen zu schreiben. - Die Funktion start() startet einen Prozess auf einem Server Modul, - Mit stop() kann ein solcher wieder angehalten werden. - getStatus() schliesslich liefert Informationen über ein Server Modul und die dort laufenden Prozesse. Durch die parametrisierung dieser Funktionen, ist es möglich, praktisch alle denkbaren Interfaces via GHWIF über das Internet abzubilden.

Das GHWIF System Hauptteil Und so funktioniert das GHWIF System: - Nehmen wir an, wir hätten irgend eine Soft- oder Hardware Einheit. - Dazu haben wir auch bereits ein Java Interface und eine Applikation. - Dann brauchen wir nur noch DIESE zwei Adapterklassen zu schreiben, und schon können wir das ganze von überall im Internet mit Hilfe von GHWIF gebrauchen. - Dabei macht das Client Module einfach eine Übersetzung der Requests nach GHWIF und leitet diese weiter zum GHWIFClient, - welcher via ClientConnection eine HTTP Verbindung zum Server aufnimmt und die Daten weiterreicht. - Der als Servlet implementierte und auf einem Apache Webserver mit Jserv Erweiterung laufende GHWIFServer entschlüsselt die Daten, überprüft mit Hilfe der Datenbank die Zugriffserlaubnis und reicht dann die Daten an das spezifische GHWIFModule weiter. - Dieses übersetzt zurück und ruft das ursprüngliche Interface auf.

X- over GHWIF Hauptteil Um XHWIF Unterstützung anbieten zu können, mussten wir also einfach die entsprechenden Interfaceklassen programmieren und schon laufen die XHWIF Applikationen und Treiber ohne Änderung über GHWIF.

Die x2ghwif Abbildung Hauptteil X2ghwif muss also einfach von XHWIF zu GHWIF übersetzen. Was einfach dadurch erreicht wird, dass die XHWIF Requests in starts mit den Funktionsnummern von -1 bis -19 übersetzt werden. G2xhwif macht auf der Serverseite einfach exakt das Gegenteil.

Hauptteil Ausblick Erweiterungen I -Client-Server Struktur

Ausblick Erweiterungen II: -HTML Interface: Hauptteil Ausblick Erweiterungen II: -HTML Interface: Datenbank verwalten via Internet -Datenbank -Bekanntmachung

Zusammenfassung Was wurde erreicht: Schluss Zusammenfassung Was wurde erreicht:  Allgemeines Interface für Boards oder Software Module  Lösung mit Java programmiert, integriert in einen Apache Webserver  Plattformunabhängig

Zusammenfassung GHWIF Lösung: Schluss Apache Webserver JDK Internet Client Files Servlets: -JSDK -Apache JServ GHWIF Server Files