FPGA Design

Der Programmspeicher kann ein Programm mit bis maximal 128 Anweisungen aufnehmen, da sieben Adressbits dafür reserviert wurden (somit 27=128 Befehle). Das Programm selbst kann sowohl in Assembler, C oder einer anderen Programmiersprache erstellt werden. In den meisten Fällen wird durch assemblieren und compilieren daraus ein Intel-Hex – Format erzeugt. Bevorzugt ist aber Binärformat, welches in VHDL einfacher zu verarbeiten ist. In der Assembler- und C -Programmierung wird jedem Befehl ein Opcode zugewiesen, dieser Teil wird normalerweise, durch einen Compiler durchgeführt. In diesem Fall handelt es sich um einen kundenspezifischen Befehlssatz, der von keinem Standard Compiler abgedeckt werden kann. Somit muss auch bedacht werden, dass in weiterer Folge ein Compiler adaptiert werden muss. [...]

Die soeben angeführten Vor- und Nachteile sind aus dem Versuch der Einbindung von unterschiedlichsten frei verfügbaren MPU Cores, wie z.B. 8051, AC8 Atmel, PIC16F84, u.s.w. entstanden. Keine der verfügbaren Cores ist nach Einbindung lauffähig, es muss zuerst mit hohem Aufwand das Design abgeändert werden, bis eine Funktion gegeben ist. Das Problem beginnt aber meist schon bei der Einbindung, wie schon bei den Nachteilen beschrieben, werden unterschiedlichste Libraries verwendet, die nicht bei jeder Entwicklungsumgebung verfügbar sind. c.) IP-Core von FPGA Hersteller Vorteile: • • • • • Optimierung auf Anwendung und Zielhardware Know How, bzw. Support ist vom Hersteller verfügbar Teure Entwicklungswerkzeuge werden in der Firma nicht benötigt Garantie auf Korrektheit Verkürzung der Durchlaufzeiten [...]

In dieser Arbeit wird gezeigt, dass kundenspezifische Mikroprozessoren, bzw. Mikrocontroller, die sich bereits im Einsatz befinden, jederzeit als Softcore auf einer FPGA-Plattform nachgebildet werden können. Sowie auch jederzeit ein kundenspezifischer Controller erstellt werden kann. Weiters werden Möglichkeiten der Verifikationsstrategien aufgezeigt, um der Forderung nach Funktion und Korrektheit gerecht zu werden. Es wird auch aufgezeigt, dass schon mit einfacher, frei erhältlicher Entwicklungssoftware anspruchsvolle und komplexe Designs erstellt werden können. Es werden bereits am Markt Opencores angeboten, sei es jetzt von den FPGA-Herstellern selbst, Firmen, Schulen oder Universitäten. Prinzipiell ist hier zwischen frei verfügbaren sowie kostenpflichtigen Cores zu unterscheiden. Die kostenpflichtigen Cores sind meist sehr teuer, und es werden weiters auch noch jährliche Lizenzgebühren verlangt. Bei den frei verfügbaren Cores besteht das Problem, das viele Cores nicht funktionieren, die Dokumentation sehr dürftig ist, die Entwicklungstools und somit die verwendeten Libraries sehr unterschiedlich sind, natürlich auch nur speziell für eine bestimmte Plattform von FPGAs nutzbar sind. Die Designs sind auch absolut nicht in Bezug auf benötigte Chipfläche/Gatter optimiert, sodass man noch keinen Gedanken daran verlieren kann, FPGAs als z.B. möglichen Mikrocontroller Ersatz zu verwenden, da die Preisunterschiede noch immens sind. Somit ist immer noch überlegenswert, wenn eine bestimmte Core on Chip benötigt wird, diese entsprechend den Anforderungen selbständig und in Modulbauweise aufzubauen, bzw. Libraries zu erstellen. Diese Einzelmodule können einfacher verifiziert und in Einsatz genommen werden. Mit einer solchen Entwicklungsstruktur ist natürlich eine „System on Chip“ Entwicklung bei weitem einfacher zu realisieren, und die Entwicklungsdurchlaufzeiten können entsprechend reduziert werden, welches heutzutage eines der höchsten Ziele darstellt. Im Zuge dieser Arbeit wird die Entwicklung eines Mikrocontroller-Core Moduls für eine FPGA –Plattform mit der Hardwarebeschreibungssprache VHDL gezeigt, sowie dessen Verifikation und Implementierung. [...]